如何以及为什么使用refresh_token处理jwt令牌过期，还有其他选择吗？

Question

我有两场战争：app.war（struts web 应用程序）和rest.war（经典的rest api）。

app.war通过 jwt 令牌进行访问rest.war，该令牌在用户登录成功后生成app.war。

当用户使用时，需要通过使用jwt token从jsp发送ajax调用来a.war获取一些数据。rest.wara.war

jwt令牌的过期时间是15分钟，而会话超时时间app.war是1小时。

但是，如果 jwt 令牌过期，即使弹出要求用户重新登录，用户仍然可以访问app.war。

有一种选择：使用access_token和refresh_token，如果access_token过期，则使用refresh_token获取新的access_token和refresh_token。

对于这种方法，我有一些疑问：

首先，为什么使用两个令牌？因为我认为它们是相同的，只是refresh_token寿命比 access_token并使用refresh_token新的更长access_token，所以为什么不只是access_token将其过期时间设置得更长呢？

其次access_token，生成和的算法是否相同refresh_token，只是它们的过期时间不同？

第三，如果客户端使用令牌执行多个 api 调用（同步和异步），如果其中一个调用返回 401（令牌过期），如何处理？

Answer 1

正如您所说，refresh_token 是处理 jwt 过期的推荐替代方案。

为什么使用两个令牌？

因为使用两个令牌（access_token和refresh_token）是信任OAuth 2.0授权框架的世界级公司（google、azure、amazon等）使用的经过验证的策略

• https://www.rfc-editor.org/rfc/rfc6749

它是互联网工程任务组 (IETF) 的产品，而互联网工程任务组 (IETF) 是一个开放标准组织，负责开发和推广自愿性互联网标准，特别是构成互联网协议套件的标准。

您可以严格遵守其规范来使用oauth2框架，创建并混合关注您的自定义需求，或者开发具有新概念的新框架。

那么为什么不直接使用 access_token 并将其过期时间设置得更长呢？

Oauth2 规范不推荐使用不可过期的令牌。令牌词本身意味着一种可以过期的东西。如果它没有过期，我们可以使用密码。

例如，让我们想象一个移动应用程序需要令牌来下载一些用户信息。如果令牌未过期，小偷就可以窃取移动应用程序、输入并访问用户信息。但由于令牌意味着过期，窃贼可能有时间限制的访问。此外，用户可以在盗窃时撤销令牌，因此窃贼无法访问。

通常，当令牌过期时，会强制登录。但有一些要求，用户不想每 3600 毫秒登录并再次登录。因此，refresh_token有助于不打扰我们的用户并在无需人工登录的情况下获得新的access_token。现在，如果refresh_token没有过期会发生什么？我们可以创建几个月或几年的访问令牌吗？这就是为什么refresh_token也必须过期

生成access_token和refresh_token的算法是否相同，只是它们的过期时间不同？

我实现了一种安全服务器，并使用相同的算法但具有不同的过期时间。但我添加了一个额外的声明来区分它们：

• 如何在安全服务器的验证阶段区分refresh_token和access_token？

多次调用需要access_token

在这种情况下，如果每次用户登录时更新令牌，您将拥有一个可供使用的 access_token，其生命周期为 3600 毫秒。

之后，您的用户是一种机器人（或者是您的网络的功能/要求）并开始使用多种表单，这些表单对附加 access_token 的其余 api 执行多次调用。

如果我们在 3601 毫秒内，在下一次来自 Web 的 api 调用中，api 必须返回 403 错误并显示一个经典的弹出窗口：会话已过期，请单击此处重新登录...

如果您的要求是避免此弹出窗口，您可以选择以下方法之一：

• 出现 403 错误时使用刷新令牌更新令牌。在这种情况下，您可以使用axios-retry来处理错误重试。
• 登录后，启动异步任务以小于令牌过期的时间间隔更新令牌。在我们的示例中为 3400 毫秒。因此，来自您的 Web 的 api 调用永远不会失败

建议

在后端层而不是前端（ajax）层执行access_token和refresh_token交换。

因此，攻击者永远不会知道您的端点来获取令牌或刷新它们。