Security 访问令牌和刷新令牌最佳实践？如何实施接入与控制；刷新令牌

我正在做SPA，并决定使用JWT进行身份验证/授权，我读了一些关于令牌与cookie的博客。我了解cookie授权的工作原理，也了解基本令牌授权的工作原理。问题是，我不知道刷新令牌如何适应它，在我看来，它降低了安全性。在我看来，让我解释一下：

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

• 这种方法容易受到CSRF（跨站点请求伪造）的攻击，为了防止CSRF，您可以将令牌与cookie一起使用

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

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

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

访问令牌和刷新令牌 所以我想使用刷新令牌来防止用户需要经常登录。假设在身份验证方面，我给用户访问令牌和刷新令牌，当用户访问令牌到期时，用户可以使用刷新令牌来获取新的访问令牌，这是我没有得到的。

• 假设我将访问令牌存储在本地存储器中。如果我还将刷新令牌存储在本地存储中，我看不出它有什么用处。因为若攻击者可以访问本地存储并获得访问令牌，那个么他也可以获得刷新令牌。所以在这种情况下，为什么不让访问令牌长寿呢
• 若将刷新令牌存储为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令牌||
|        |                                           |               |
||关于访问令牌和刷新令牌
将访问令牌视为“脏”令牌。你分享了很多。我不必是你将令牌传递给的一台服务器，可以是多台。因此，攻击面上升。如果一台服务器做了一些愚蠢的事情，比如将令牌写入服务器日志，然后将日志公开给全世界，那么您需要限制负面影响，因此访问令牌是短期的，以限制攻击者可以进行恶意操作的时间

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

关于你的解决方案
在我看来很好。也许我不会为了省力而实现XSRF令牌。我的意思是，如果有人试图通过CSRF进行攻击，会发生什么最糟糕的事情？他可能会让你刷新你的令牌。但令牌不会仅因为CSRF而暴露给攻击者

还有一件事
我喜欢你的问题。写得真不错！：）
 是否存在任何架构设计，客户端从未访问过刷新令牌，并且对新访问令牌的请求都是在后台管理的（具有前端->后端->授权服务器架构，后端实现所有逻辑）。有人听说过这个主意吗？