security - 访问 token 和刷新 token 最佳实践？如何实现访问和刷新 token

Question

我正在制作 SPA，并决定使用 JWT 进行身份验证/授权，并且我已经阅读了一些关于 Tokens 与 Cookies 的博客。我了解 cookie 授权的工作原理，并了解基本 token 授权的工作原理。问题是，我看不到刷新 token 如何适应它，在我看来它降低了安全性。让我解释一下，正如我所看到的:
Cookie 方法
当您通过用户名和密码对用户进行身份验证时，您将创建与该用户关联的 session ID。并将其设置为 cookie，每次客户端调用您的服务器时，它都会发送该 cookie，服务器可以在数据库或其他服务器端存储中查找关联用户。

这种方法容易受到 CSRF (Cross Site Request Forgery) 的攻击 为防止 CSRF 您可以使用带有 cookie 的 token

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

代币方式
当您通过用户名和密码对用户进行身份验证时，您将创建一个签名 token ，在有效负载中包含到期日期、电子邮件地址或用户 ID、角色等。对于安全 token ，应具有较短的到期时间。 token 可以存储在本地存储、 session 存储、cookies 的任何地方。我将使用本地存储或 session 存储来防止 XSRF。

这容易受到 XSS(跨站点脚本)的攻击，但您可以通过验证 HTML 输入来防止这种情况发生。

由于 token 生命周期短，当 token 过期时，用户必须重新登录。

访问 token 和刷新 token
所以我想使用刷新 token 来防止用户需要不断登录。所以让我们说在身份验证上，我给用户访问 token 和刷新 token ，当用户访问 token 过期时，用户可以使用刷新 token 来获取新的访问 token ， 这是我不明白的。

假设我将访问 token 存储在本地存储中。如果我还在本地存储中存储 Refresh token ，我看不到它有任何用处。因为如果攻击者可以访问本地存储并获得访问 token ，他也可以获得刷新 token 。所以在这种情况下，为什么不让访问 token 长生命周期。

如果您将 Refresh token 存储为 cookie，它很容易受到 XSRF 的攻击，然后攻击者可以获得新的访问 token ，并使用它。同样在这一点上，为什么不直接使用 Cookie 授权？因为您已经必须查找本地存储以获取刷新 token ，尽管与纯 cookie 授权相比，这种情况发生的频率较低。

最佳做法是什么？
目前我正在考虑使用:

访问 token (本地存储，短暂存在)

刷新 token (Cookie，万岁)

刷新 token 的 token (为了防止 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    +---------------+

每次使用刷新 token 时，服务器都会发出新的 XSRF token (使用一个 XSRF token 后，它停止工作，服务器发出新的 token )。 你怎么看这个实现？ 在我看来，这将服务器查找限制为数据库，因为它使用访问 token ，访问 token 是短暂的，并且用户不必经常登录，因为它使用刷新 token /cookie 女巫受 XSRF token 保护。
这个可以吗 ？
谢谢 !

Answer 1

关于访问 token 和刷新 token
将访问 token 视为“脏” token 。 token 你分享了很多。我不必是您将 token 传递给的一台服务器，可以是多台。因此，攻击面上升。如果一台服务器做了一些愚蠢的事情，比如将 token 写入服务器日志，然后将日志暴露给全世界，你想限制负面影响，因此访问 token 是短暂的，以限制攻击者可以做一些恶意的事情的时间。
另一方面，刷新 token 是“干净的” token 。你为自己存储的东西，只有在你必须的时候才能记住和使用它。当然，如果攻击者获得了对您的计算机和用户代理的物理访问权限，那么游戏就结束了。但在这里我们尝试防止远程攻击者。仅在与身份验证服务器或身份验证端点通信时才应使用刷新 token 。如果您决定将其设为 cookie - 您可以 - 只需记住将目录路径限制为仅将 token 传递到的 REST 端点。
关于你的解决方案
我的眼睛看起来不错。也许我不会为了省力而实现 XSRF token 。我的意思是，如果有人试图通过 CSRF 进行攻击，可能发生的最糟糕的事情是什么？他也许能让你刷新你的 token 。但是 token 不会仅仅因为CSRF而暴露给攻击者。
还有一件事
我喜欢你的问题。写的真的很好! :)