刷新令牌有必要吗？
我最近一直在搜索刷新令牌和旋转访问令牌，我突然想到了一些东西。
为什么不使用一个令牌而不是访问令牌和刷新令牌？在该令牌有效载荷（声明）中包含一个验证日期，并将验证期设置得很低（就像访问令牌一样），将到期日期设置得很高（就像刷新令牌一样）。
如果验证日期超过服务器上的日期但未过期，服务器将颁发新令牌并使旧令牌无效（通过任何方式，例如令牌黑名单等，就像 AT 过期和使用刷新令牌颁发新令牌一样），如果令牌过期，则服务器只需拒绝请求并请求授权（就像刷新令牌过期一样）。
如果这种方法可行，那么为什么我们使用2个令牌，这使得开发过程更加困难？
共有1个答案
我想你忘记了一些事情。
刷新令牌存储在服务器上。访问令牌不是。访问令牌是独立的。这就是它们被称为不记名代币的原因。令牌持有者被授权访问。
这意味着，如果访问令牌被恶意方窃取，只要它没有过期，就可以使用。访问令牌被认为是安全的，因为其寿命有限。
以便使用刷新令牌来请求新的访问令牌。你需要有客户id，用来认证的客户密码。您还需要能够监听刷新令牌响应的有效重定向uri之一。
-
我引用的是另一篇讨论在JWT中使用刷新令牌的SO帖子。 JWT（JSON Web令牌）自动延长到期时间 我有一个应用程序，它具有一个非常通用的体系结构，在这个体系结构中，我的客户机（web和移动）与一个REST API对话，然后再与一个服务层和数据层对话。 令牌每小时由客户端刷新一次。 如果用户令牌未被刷新（用户处于非活动状态且应用程序未打开）并且过期，则无论何时他们想要恢复，都需要登录。 我看到
-
授权服务器可以给Web应用客户端和本机应用程序客户端颁发刷新令牌。 刷新令牌在传输和储存时必须保持机密性，并只与授权服务器和刷新令牌被颁发的客户端共享。授权服务器必须维护刷新令牌和它被颁发给的客户端之间的绑定。刷新令牌必须只能使用带有RFC2818定义的服务器身份验证的1.6所述的TLS 传输。 授权服务器必须验证刷新令牌和客户端身份之间的绑定，无论客户端身份是否能被验证。当无法进行客户端身份验证
-
刷新令牌是用于获取访问令牌的凭据。刷新令牌由授权服务器颁发给客户端，用于在当前访问令牌失效或过期时，获取一个新的访问令牌，或者获得相等或更窄范围的额外的访问令牌（访问令牌可能具有比资源所有者所授权的更短的生命周期和更少的权限）。颁发刷新令牌是可选的，由授权服务器决定。如果授权服务器颁发刷新令牌，在颁发访问令牌时它被包含在内（即图1中的步骤D）。 刷新令牌是一个代表由资源所有者给客户端许可的授权的字
-
我对oauth2中的刷新令牌有点困惑。如它所说的访问令牌限制了黑客可以使用用户凭证的1小时的时间窗口，刷新令牌是万岁令牌，可以用来重新创建访问令牌。 我很困惑，如果有人从cookie中窃取了访问令牌，他也可以窃取刷新令牌，并可以使用刷新令牌创建新的访问令牌，因为我在JQuery中有ajax请求（客户端）
-
我的应用程序使用Google refresh令牌（从Google获得access_token)。我在这里有两个问题： 我知道谷歌刷新令牌不会在6个月内过期（见这里的文档）；假设我在1月1日下午5:00pm获得了一个刷新令牌，并且我的应用程序在1月1日下午5:30从Google请求了另一个刷新令牌，那么旧的刷新令牌是否仍然有效（显然旧的还没有过期）？--基本上，我询问新发出的refresh_toke
-
登录时，将从服务器发送JWT访问令牌，并保存在RN中的AsyncStorage中。 现在，我希望用户保持登录5年，直到他们: > < li> 注销 管理员撤销了他们的令牌 他们在3台设备上登录，在其中一台设备上更改密码，这应该从其他2台设备上注销他们，直到他们在这些设备上再次登录 丢失他们的电话，并从另一个设备登录以从所有设备注销 看起来我不得不在数据库中存储JWT令牌(我知道这不是JWT令牌的重