访问令牌和刷新令牌最佳实践？如何实施访问和刷新令牌

Question

我正在制作 SPA，并决定使用 JWT 进行身份验证/授权，并且我阅读了一些关于 Tokens 与 Cookies 的博客。我了解 cookie 授权的工作原理，并了解基本令牌授权的工作原理。问题是，我不明白刷新令牌如何融入其中，在我看来它降低了安全性。让我解释一下，据我所知：

Cookie 方法

当您通过用户名和密码验证用户身份时，您将创建与该用户关联的会话 ID。并将其设置为 cookie，每次客户端调用您的服务器时，它都会发送该 cookie，并且服务器可以在数据库或其他服务器端存储中查找关联的用户。

• 这种方法容易受到CSRF（跨站请求伪造）的影响，要防止CSRF，您可以使用带有cookie的令牌

• 服务器还需要不断查找存储以查看 cookie 指向哪个用户。

代币方法

当您通过用户名和密码对用户进行身份验证时，您将创建一个签名令牌，并在有效负载中包含到期日期、电子邮件地址或用户 ID、角色等。对于安全令牌来说，过期时间应该很短。令牌可以存储在任何地方本地存储、会话存储、cookie。我将使用本地存储或会话存储来防止 XSRF。

• 这容易受到 XSS（跨站脚本）攻击，但您可以通过验证 HTML 输入来防止这种情况。
• 由于 token 的生命周期较短，当 token 过期后，用户必须重新登录。

访问令牌和刷新令牌

所以我想使用刷新令牌来防止用户需要不断登录。因此，在身份验证上，我给用户访问令牌和刷新令牌，当用户访问令牌过期时，用户可以使用刷新令牌来获取新的访问令牌，这是我没有得到的。

• 假设我将访问令牌存储在本地存储中。如果我还将刷新令牌存储在本地存储中，我看不到它有任何用处。因为如果攻击者可以访问本地存储并获取访问令牌，他也可以获得刷新令牌。那么在这种情况下，为什么不让 Access token 长期存在呢。
• 如果您将刷新令牌存储为 cookie，则它很容易受到 XSRF 的攻击，然后攻击者可以获取新的访问令牌并使用它。同样在这一点上，为什么不直接使用Cookie授权呢？因为您已经必须查找本地存储来获取刷新令牌，尽管这种情况发生的频率比纯 cookie 授权要低。

最佳实践是什么？

目前我正在考虑使用：

• 访问令牌（本地存储，短暂）
• 刷新令牌（Cookie，长命）
• 刷新令牌的令牌（为了防止 XSFR，本地存储，使用一次后就会过期）

假设它看起来像这样：

  +--------+                                           +---------------+
  |        |------------ Authorization Grant --------->|               |
  |        |                                           |               |
  |        |<--------------- Access Token -------------|               |
  |        |               & Refresh Token (cookie)    |               |
  |        |               & XSRF Token                |               |
  |        |                                           |               |
  |        |                                           |               |
  |        |--------- Access Token ------------------->|               |
  |        |                                           |               |
  |        |<----- Protected Resource -----------------|               |
  | Client |                                           |     Server    |
  |        |--------- Access Token ------------------->|               |
  |        |                                           |               |
  |        |<----- Invalid Token Error ----------------|               |
  |        |                                           |               |
  |        |                                           |               |
  |        |---------------- Refresh Token ----------->|               |
  |        |               & XSRF Token                |               |
  |        |                                           |               |
  |        |<--------------- Access Token -------------|               |
  |        |               & XSRF Token                |               |
  +--------+               & Optional Refresh Token    +---------------+

每次使用刷新令牌时，服务器都会颁发新的 XSRF 令牌（使用一个 XSRF 令牌后，它会停止工作，服务器会颁发新的 XSRF 令牌）。 您对这个实现有何看法？ 在我看来，这限制了服务器对数据库的查找，因为它使用访问令牌，访问令牌的寿命很短，并且用户不必不断登录，因为它使用刷新令牌/cookie，女巫受到保护通过 XSRF 代币。

这样可以吗？

谢谢！

Answer 1

关于访问令牌和刷新令牌

将访问令牌视为“脏”令牌。您分享了很多令牌。您将令牌传递到的服务器不必是一台，可以有很多台。因此，攻击面上升。如果一台服务器做了一些愚蠢的事情，例如将令牌写入服务器日志，然后将日志公开给全世界，您希望限制负面影响，因此访问令牌是短暂的，以限制攻击者执行恶意操作的时间。

另一方面，刷新令牌是“干净”的令牌。您为自己存储的东西以便记住并仅在必要时使用它。当然，如果攻击者获得了对您的计算机和用户代理的物理访问权限，那么游戏就结束了。但在这里我们试图防止远程攻击者。刷新令牌仅应在与身份验证服务器或身份验证端点通信时使用。如果您决定将其设为 cookie - 您可以 - 只需记住将目录路径限制为令牌要传递到的 REST 端点即可。

关于您的解决方案

我的眼睛看起来不错。也许我不会为了省力而实施 XSRF 令牌。我的意思是，如果有人试图通过 CSRF 进行攻击，可能发生的最糟糕的事情是什么？他也许能让你刷新你的令牌。但仅仅因为 CSRF，令牌不会暴露给攻击者。

还有一件事

我喜欢你的问题。确实写得很好！ :)