刷新令牌是不是需要过期的 JWT 才能创建新的访问令牌？

Posted 2023-02-19

【中文标题】刷新令牌是不是需要过期的 JWT 才能创建新的访问令牌？

【英文标题】：Does refresh token requires Expired JWT for creating new access token?刷新令牌是否需要过期的 JWT 才能创建新的访问令牌？

【发布时间】：2021-08-26 11:24:48

【问题描述】：

在我最近的遭遇中，我试图在前端实现 JWT 令牌的安全存储。 我之前的方法是将access_token 和refresh_token 存储在容易受到XSS 攻击的sessionStorage 中。现在，当access_token 过期时，我将调用/refresh 端点来获取新的access_token。在这里，我将过期的 JWT 传递给 Authorization Header。这里的想法是保护您的刷新端点并确保只有登录用户才请求令牌。

之后，我们更改实现以防止 XSS 和 CSRF。并随之而来， LocalStorage vs. Cookies

其中建议，将您的访问令牌存储在内存中，并将刷新令牌存储在 cookie 中。所以从FE，我们无法访问cookie。（HTTPOnly cookie）和access_token

现在真正的挑战是当页面刷新时，我们会丢失 access_token，因为我们将其存储到内存中，并且 API 要求提供已过期的 JWT 令牌。

所以我的问题是，/refresh 端点是否需要过期的 JWT 令牌，或者在没有 JWT 令牌的情况下使用刷新令牌是一种好习惯。

【参考方案1】：

内存中的访问令牌和 cookie 中的刷新令牌是 SPA 的一个受人尊敬的选项。有一个名为TMI BFF 的新兴标准值得关注，因为它有望将最佳实践形式化。

cookie 应具有符合以下条件的属性：

仅 HTTP 安全 AES 256 加密 SameSite=strict

使用“auth cookie”也不能要求访问令牌，因为这些用例不适用于客户端：

用户刷新页面 用户打开新的浏览器标签

如OWASP Double Submit Pattern 中所述，一种选择是发送防伪令牌以及cookie。在浏览器中，防伪令牌需要存储在本地存储中才能使上述用例正常工作。这不是 100% XSS 安全的，但也不是浏览器中的任何其他内容。

我的一些代码在后端 API 中使用这种方法作为 OAuth 工作的一部分：

SPA Code OAuth Code in API

像很多人一样，我有兴趣了解 SPA 最佳实践是如何演变的。值得一提的是，有些人建议通过“后端为前端”代理所有 API 调用：

目前被认为更安全 但它也增加了复杂性，并可能降低了某些领域的功能

【讨论】：

感谢您提出更多选择。我去看看。