cookies - 为什么将刷新令牌存储在仅 HTTP 的 Cookie 中以防止 CSRF 攻击？

Question

我刚读到这篇文章

https://hasura.io/blog/best-practices-of-using-jwt-with-graphql/

总之，他们建议将 JWT 访问令牌存储在内存中（例如作为 JavaScript 中的变量），并将刷新令牌存储在 HTTP-Only Cookie 中。

他们说：

但是通过刷新令牌间接保持我们的会话，我们可以防止我们使用 JWT 令牌时会遇到的直接 CSRF 漏洞。

但它是否将 Refresh Token 存储在 HTTP-Only cookie 中仍然容易受到 CSRF 攻击？例如， evilsite.com 可以向 /refreshtoken 端点发出请求以获取新的 JWT 访问令牌。我对 HTTP-Only cookie 的理解是无法从 JavaScript 读取 cookie，但它会在发出 HTTP 请求时自动发送，就像 evilsite.com 所做的那样。（如我错了请纠正我）。

标签： cookiesjwtrefresh-token

Answer 1

如果小心使用，刷新 cookie 中的令牌和内存中的访问令牌可能是一个很好的模型。希望在BFF-TMI等标准中提供一些更好的指导。

cookie 应该具有这些属性，并且 SameSite 属性意味着 evilsite 无法发送它，因此从 CSRF 的角度来看它是好的。

• 仅 HTTP
• 安全的
• AES256 加密
• SameSite=严格

OWASP 的CSRF 指南似乎建议同时使用 SameSite 和 CSRF 令牌作为首选选项。

这里不感兴趣的是我目前如何在 SPA 代码示例中实现事物 - 如果从以下方面借用想法很有用：

• SPA OAuth 代码
• 后端 API OAuth 代码

随着该领域指导的发展，我可能会改变主意。

高安全性选项？

当前的共识是，在安全性方面，以下选项是首选，尽管我希望风险和缓解措施在来年得到更好的记录：

• 将访问令牌完全排除在浏览器之外
• 通过“前端后端”代理所有 API 调用
• 观看这段富有洞察力的2021 年视频

但是，此选项可能会增加某些领域的复杂性，并且还可能会限制某些场景中的功能。

与安全性通常一样，需要权衡其他因素，选择的解决方案可能取决于数据敏感性和利益相关者关心的内容。