Jwt 我是否正确理解用于身份验证的访问和刷新令牌技术？

在做了一些关于使用JWT和访问令牌以及刷新令牌进行身份验证的研究之后。我是这样理解的

• 登录后，返回到用户访问令牌和刷新令牌（对两者使用相同的JWT技术）
• 在数据库中保存刷新令牌（一个用户可以有多个设备的多个刷新令牌）
• 每当用户发送带有无效访问令牌的请求时，请检查刷新令牌并调用另一个api以获取新的访问令牌（在客户端执行此操作）。之后，调用api以使用新的访问令牌再次获取数据
• 若刷新令牌无效，则删除其在数据库中的记录，用户必须再次登录才能获得新的刷新令牌

---

我是否正确理解访问和刷新令牌技术？请给我一些建议。提前感谢。

在您列出的4个步骤中，有些看起来或多或少是正确的，而有些则不正确。首先，我将给出为什么创建刷新令牌以及它们的主要用途的前提

使用只有访问令牌的JWT模式，当JWT令牌过期时，存在潜在的可用性问题。以银行网站为例。当用户登录时，他会收到一个具有特定到期日的JWT令牌（通常存储在令牌声明部分的

exp

键下）。如果令牌有5分钟的有效期，那么从可用性的角度来看，这意味着网站必须强制用户每5分钟手动登录一次。显然，这不是最好的用户体验，因为这意味着当令牌到期时，恰巧处于某个业务流程中间的用户可能会丢失所有这些工作。这就是刷新令牌用来缓解此问题的地方

将JWT模式与刷新令牌一起使用意味着用户同时接收访问和刷新令牌。此处的典型工作流可能是：

• 登录后，返回到用户访问令牌和刷新令牌（对两者使用相同的JWT技术）。接收方记录访问令牌何时设置为过期（例如15分钟）
• 当访问令牌到期时（例如10分钟），UI将向后端发送刷新令牌以获取新的访问令牌（和刷新令牌）。这可以明确地完成，例如，在一个网站上显示一个弹出窗口，询问用户是否想继续。或者可以在隐形模式下完成，在引擎盖下进行REST呼叫以获取新的访问令牌
• 对于无法使用刷新令牌获取新访问令牌的边缘情况，则需要身份验证的下一个用户操作将失败。在这种情况下，用户必须重定向到登录页面。但是，由于这种情况通常很少见，因此它并不取消刷新令牌模式的资格

---

我还要指出，在数据库中存储访问/刷新令牌在很大程度上违背了JWT模式的目的。使用JWT的一个主要原因是它将用户会话状态从应用程序中推到用户身上。通过在数据库中存储令牌，您完全可以使您的用户会话非常有状态，这有各种潜在的缺点。考虑上面所建议的工作流程，以避免这样做。

列出的4个步骤，有些看起来正确，而有些则不正确。首先，我将给出为什么创建刷新令牌以及它们的主要用途的前提

使用只有访问令牌的JWT模式，当JWT令牌过期时，存在潜在的可用性问题。以银行网站为例。当用户登录时，他会收到一个具有特定到期日的JWT令牌（通常存储在令牌声明部分的

exp

键下）。如果令牌有5分钟的有效期，那么从可用性的角度来看，这意味着网站必须强制用户每5分钟手动登录一次。显然，这不是最好的用户体验，因为这意味着当令牌到期时，恰巧处于某个业务流程中间的用户可能会丢失所有这些工作。这就是刷新令牌用来缓解此问题的地方

将JWT模式与刷新令牌一起使用意味着用户同时接收访问和刷新令牌。此处的典型工作流可能是：

• 登录后，返回到用户访问令牌和刷新令牌（对两者使用相同的JWT技术）。接收方记录访问令牌何时设置为过期（例如15分钟）
• 当访问令牌到期时（例如10分钟），UI将向后端发送刷新令牌以获取新的访问令牌（和刷新令牌）。这可以明确地完成，例如，在一个网站上显示一个弹出窗口，询问用户是否想继续。或者可以在隐形模式下完成，在引擎盖下进行REST呼叫以获取新的访问令牌
• 对于无法使用刷新令牌获取新访问令牌的边缘情况，则需要身份验证的下一个用户操作将失败。在这种情况下，用户必须重定向到登录页面。但是，由于这种情况通常很少见，因此它并不取消刷新令牌模式的资格

---

我还要指出，在数据库中存储访问/刷新令牌在很大程度上违背了JWT模式的目的。使用JWT的一个主要原因是它将用户会话状态从应用程序中推到用户身上。通过在数据库中存储令牌，您完全可以使您的用户会话非常有状态，这有各种潜在的缺点。考虑使用上面建议的工作流来避免这样做。

我得到它。但在这种情况下，访问令牌和刷新令牌有什么区别？在您的情况下，刷新令牌只是访问令牌的长期版本。如果用户wa