使用JWT令牌身份验证时，刷新令牌真的有必要吗？
我引用的是另一篇讨论在JWT中使用刷新令牌的SO帖子。
JWT（JSON Web令牌）自动延长到期时间
我有一个应用程序，它具有一个非常通用的体系结构，在这个体系结构中，我的客户机（web和移动）与一个REST API对话，然后再与一个服务层和数据层对话。
令牌每小时由客户端刷新一次。
如果用户令牌未被刷新（用户处于非活动状态且应用程序未打开）并且过期，则无论何时他们想要恢复，都需要登录。
我看到很多人声称使用刷新令牌的概念来使这个体验更好，然而，我没有看到这样做的好处。这似乎增加了管理它的复杂性。
-
null
共有1个答案
让我稍后再来回答您的问题，并从实际讨论刷新令牌的全部目的开始。
所以情况是：
用户打开应用程序并提供其登录凭据。现在，该应用程序很可能正在与REST后端服务进行交互。REST是无状态的，没有方法授权访问API。因此，到目前为止，在讨论中，还没有办法检查是否有授权用户正在访问API，或者只是通过一些随机请求。
假设Alice不知何故丢失了访问令牌，或者换种方式，对手Bob获得了对Alice访问令牌的访问权。现在，尽管Bob未经授权，但它可以向Alice授权的所有API发出请求。
一些我们理想中不想要的东西。
现在解决这个问题的办法是：
-
null
解决方案：这就是刷新令牌的作用。它还是一个随机的、不可预测的令牌，首先也会与访问令牌一起发布给应用程序。这个刷新令牌是一个很长时间的特殊令牌，它确保一旦访问令牌过期，它就会向服务器请求一个新的访问令牌，这样用户就不再需要在现有的访问令牌过期时重新输入他的登录凭据来检索新的授权访问令牌。
现在您可能会问，Bob也可以访问refresh令牌，这与他破坏access令牌的方式类似。是的。他可以。然而，现在很容易识别这样的事件，这在单独使用访问令牌的情况下是不可能的，并且采取必要的行动来减少所造成的损害。
怎么做？
另外，作为一个好的实践，refresh令牌应该有一个到期时间，尽管这个到期时间相当长。
-
我正在做一个项目（没有生产级别，只是为了提高我的技能），我正在使用JWT来处理身份验证。从我所读到的内容来看，仅使用JWT作为访问令牌是非常不安全的，因此我们需要刷新令牌。因此，在登录时，服务器返回一个访问令牌和一个刷新令牌（我将存储在httpOnly cookie中）。访问令牌在短时间内到期，但刷新令牌在到期时用于获取新令牌。 我的问题是，我们何时使用刷新令牌来获取新的访问令牌？是当用户想要获得
-
我试图弄清楚我应该如何坚持身份验证。 假设用户使用电子邮件和密码成功进行身份验证。然后服务器生成并返回两个令牌： accesstoken（jwt过期15分钟）将存储在浏览器存储中 refreshtoken（jwt过期7天）作为安全cookie 当将访问令牌存储在本地存储（或会话存储）中时，React 应用程序将简单地检查它是否存在于存储中并继续渲染私有路由。因此，这意味着如果用户有一个无效/被盗的
-
我最近一直在搜索刷新令牌和旋转访问令牌，我突然想到了一些东西。 为什么不使用一个令牌而不是访问令牌和刷新令牌？在该令牌有效载荷（声明）中包含一个验证日期，并将验证期设置得很低（就像访问令牌一样），将到期日期设置得很高（就像刷新令牌一样）。 如果验证日期超过服务器上的日期但未过期，服务器将颁发新令牌并使旧令牌无效（通过任何方式，例如令牌黑名单等，就像 AT 过期和使用刷新令牌颁发新令牌一样），如果令
-
我试图用PHP为两个主题相连的领域创建一个简单的SSO系统。 因此，我想知道是否可以将包含用户用户名的签名JWT令牌从域a存储到本地存储。然后使用来自域B的相同密钥来验证JWT，这将导致成功的身份验证。 我在谷歌搜索了一些答案，我发现其中一些包含了一个中间认证域，它将负责认证。但我只想把我有的两个域联系起来。 谢了。
-
我在做一个全堆栈的web应用程序。我的前端由angular-cli组成，后端由node+Express构建。
-
编辑： 阅读有关bug的讨论：https://github.com/tymondesigns/jwt-auth/issues/83 我原来的问题是： 我正在使用jwt auth my protected resources实现，该资源需要经过身份验证的用户，代码如下： 当用户在API上登录时，将创建一个授权令牌，并将响应授权标头发送到调用资源的客户端应用程序。因此，客户端应用程序在截获任何响应的头