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

Emi*_*las 15 security cookies authorization token

我正在制作 SPA,并决定使用 JWT 进行身份验证/授权,并且我已经阅读了一些关于 Tokens 与 Cookies 的博客。我了解 cookie 授权的工作原理,并了解基本令牌授权的工作原理。问题是,我看不到刷新令牌如何适应它,在我看来它降低了安全性。让我解释一下,正如我所看到的:

Cookie 方法

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

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

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

代币方式

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

  • 这容易受到 XSS(跨站点脚本)的攻击,但您可以通过验证 HTML 输入来防止这种情况发生。
  • 由于令牌生命周期短,当令牌过期时,用户必须重新登录。

访问令牌和刷新令牌

所以我想使用刷新令牌来防止用户需要不断登录。所以让我们说一下身份验证,我给用户访问令牌和刷新令牌,当用户访问令牌过期时,用户可以使用刷新令牌来获取新的访问令牌,这是我没有得到的。

  • 假设我将访问令牌存储在本地存储中。如果我还在本地存储中存储 Refresh 令牌,我看不到它有任何用处。因为如果攻击者可以访问本地存储并获得访问令牌,他也可以获得刷新令牌。所以在这种情况下,为什么不让访问令牌长寿命。
  • 如果您将 Refresh 令牌存储为 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    +---------------+
Run Code Online (Sandbox Code Playgroud)

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

这个可以吗 ?

谢谢 !

Mar*_*ski 14

关于访问令牌和刷新令牌

将访问令牌视为“脏”令牌。令牌你分享了很多。我不必是您将令牌传递给的一台服务器,可以是多台。因此,攻击面上升。如果一台服务器做了一些愚蠢的事情,比如将令牌写入服务器日志,然后将日志暴露给全世界,你想限制负面影响,因此访问令牌是短暂的,以限制攻击者可以做一些恶意的事情的时间。

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

关于你的解决方案

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

还有一件事

我喜欢你的问题。写的真的很好!:)

  • 是否有任何架构设计使客户端永远无法访问刷新令牌,并且对新访问令牌的请求全部在幕后管理(具有前端 -&gt; 后端 -&gt; 授权服务器架构,后端实现所有逻辑)。有人听说过这个想法吗? (5认同)