为什么刷新令牌要保存在服务器端？
Why should refresh tokens be saved in the server side?
我知道访问令牌不会（通常）保存在服务器端，只是使用一些密钥和算法进行验证。但是，正常的行为似乎是在服务器端（即数据库）保存一个刷新令牌，并在用户尝试刷新其访问令牌时将其与用户的进行比较。我的问题是为什么不以验证访问令牌的方式验证刷新令牌？
如果令牌是针对数据库验证的 ID，通常会更安全，因为这允许随时撤销令牌（通过将其从数据库中删除或将其标记为无效）。
不能撤销自验证令牌，例如 JWT（不使用数据库，这会破坏使用自验证令牌的大部分好处）- 它们只能过期。因此，它们的到期时间应该很短。自验证令牌的好处不仅在于性能，还在于消除依赖性，因为资源服务器不需要连接到授权服务器拥有的数据库。相反，它可以使用受信任的 public 密钥自行验证令牌。
使用数据库也更容易实现，因为大多数 Web 应用程序已经有一个，而且自验证令牌很容易出错（有许多 JWT 库存在缺陷或错误的默认设置）。
刷新令牌仅用于请求新的访问令牌，因此性能并不重要。请求被发送到授权服务器，"owns" 任何与授权相关的数据库，因此它不会添加任何不需要的依赖项。
请注意，访问令牌不必是自验证令牌。如果它们也只是针对数据库验证的 ID，那就太好了。访问令牌和刷新令牌之间的分离使得选择使用自验证访问令牌的实现成为可能。
我知道访问令牌不会（通常）保存在服务器端，只是使用一些密钥和算法进行验证。但是，正常的行为似乎是在服务器端（即数据库）保存一个刷新令牌，并在用户尝试刷新其访问令牌时将其与用户的进行比较。我的问题是为什么不以验证访问令牌的方式验证刷新令牌？
如果令牌是针对数据库验证的 ID，通常会更安全，因为这允许随时撤销令牌（通过将其从数据库中删除或将其标记为无效）。
不能撤销自验证令牌，例如 JWT（不使用数据库，这会破坏使用自验证令牌的大部分好处）- 它们只能过期。因此，它们的到期时间应该很短。自验证令牌的好处不仅在于性能，还在于消除依赖性，因为资源服务器不需要连接到授权服务器拥有的数据库。相反，它可以使用受信任的 public 密钥自行验证令牌。
使用数据库也更容易实现，因为大多数 Web 应用程序已经有一个，而且自验证令牌很容易出错（有许多 JWT 库存在缺陷或错误的默认设置）。
刷新令牌仅用于请求新的访问令牌，因此性能并不重要。请求被发送到授权服务器，"owns" 任何与授权相关的数据库，因此它不会添加任何不需要的依赖项。
请注意，访问令牌不必是自验证令牌。如果它们也只是针对数据库验证的 ID，那就太好了。访问令牌和刷新令牌之间的分离使得选择使用自验证访问令牌的实现成为可能。