为什么在身份验证期间使用JWT刷新令牌可以防止CSRF？
使用刷新令牌可以缓解CSRF攻击。第一条规定：
刷新令牌由auth服务器作为HttpOnly cookie发送到客户端，并由浏览器在/refresh_token API调用中自动发送。因为客户端Javascript不能读取或窃取HttpOnly cookie，所以这比将其作为普通cookie或在LocalStorage中持久化要好一些。这种方法也可以免受CSRF攻击，因为即使表单提交攻击可以调用/refresh_token API，攻击者也无法获得返回的新JWT令牌值。
第二篇文章说了类似的话：
-
null
在我看来，实际上防止CSRF攻击的方法是使用sameSite cookie，或者使用某种防伪令牌。
共有1个答案
新的jwt不会作为cookie从标识提供程序返回。这没有多大意义，因为不同来源的客户机将无法读取它。相反，令牌在响应正文中传递，甚至在url中传递（在这种情况下通常不是令牌，但我们不要深究）。
因此，idp有它的httpOnly cookie来对用户进行身份验证，以某种不是cookie的方式发出新的令牌，客户机将适当来源（不是idp）的令牌存储在例如LocalStorage中。这样，对资源服务器的任何调用都不会受到csrf的攻击，因为需要从LocalStorage显式添加令牌。Attacker.com可以调用idp来发布新的令牌（“CSRF”），但由于相同的来源策略，Attacker.com将无法访问该令牌，因此它不可利用。
请注意，即使新令牌作为idp的cookie返回并由客户机从中读取，也仍然可以，因为idp不会对该令牌执行任何操作，资源服务器(~API)也不会自动接收它。
-
我在做一个全堆栈的web应用程序。我的前端由angular-cli组成，后端由node+Express构建。
-
我正在做一个项目（没有生产级别，只是为了提高我的技能），我正在使用JWT来处理身份验证。从我所读到的内容来看，仅使用JWT作为访问令牌是非常不安全的，因此我们需要刷新令牌。因此，在登录时，服务器返回一个访问令牌和一个刷新令牌（我将存储在httpOnly cookie中）。访问令牌在短时间内到期，但刷新令牌在到期时用于获取新令牌。 我的问题是，我们何时使用刷新令牌来获取新的访问令牌？是当用户想要获得
-
我引用的是另一篇讨论在JWT中使用刷新令牌的SO帖子。 JWT（JSON Web令牌）自动延长到期时间 我有一个应用程序，它具有一个非常通用的体系结构，在这个体系结构中，我的客户机（web和移动）与一个REST API对话，然后再与一个服务层和数据层对话。 令牌每小时由客户端刷新一次。 如果用户令牌未被刷新（用户处于非活动状态且应用程序未打开）并且过期，则无论何时他们想要恢复，都需要登录。 我看到
-
编辑： 阅读有关bug的讨论：https://github.com/tymondesigns/jwt-auth/issues/83 我原来的问题是： 我正在使用jwt auth my protected resources实现，该资源需要经过身份验证的用户，代码如下： 当用户在API上登录时，将创建一个授权令牌，并将响应授权标头发送到调用资源的客户端应用程序。因此，客户端应用程序在截获任何响应的头
-
我试图弄清楚我应该如何坚持身份验证。 假设用户使用电子邮件和密码成功进行身份验证。然后服务器生成并返回两个令牌： accesstoken（jwt过期15分钟）将存储在浏览器存储中 refreshtoken（jwt过期7天）作为安全cookie 当将访问令牌存储在本地存储（或会话存储）中时，React 应用程序将简单地检查它是否存在于存储中并继续渲染私有路由。因此，这意味着如果用户有一个无效/被盗的
-
当用户发送他的用户名/密码时，服务会发送回JWT，该JWT存储在客户端的localStorage中。这个很管用。但是，我想使用刷新令牌继续向客户端发出新的JWT，使用户在使用该应用程序时保持登录状态。这些刷新令牌应该发在哪里？是否应在用户发送其用户名/密码时发出？如果是这样，那么在tymon/jwt-auth库中似乎没有一种方法可以将刷新令牌发送到客户机。请帮帮我，我很难想清楚这是怎么工作的。