为什么使用 JWT 刷新令牌可以在身份验证过程中防止 CSRF？

Question

我读过一些关于 JWT 刷新令牌及其使用方式/原因的文章。我在这里看到提到的一件事： https: //hasura.io/blog/best-practices-of-using-jwt-with-graphql/#persistance和这里​​： https: //dev.to/cotter/localstorage-vs -cookies-all-you-need-to-know-about-storing-jwt-tokens-securely-in-the-front-end-15id

使用刷新令牌可以减轻 CSRF 攻击。第一篇文章指出：

刷新令牌由身份验证服务器作为 HttpOnly cookie 发送到客户端，并由浏览器在 /refresh_token API 调用中自动发送。由于客户端 Javascript 无法读取或窃取 HttpOnly cookie，因此这比将其保留为普通 cookie 或保存在本地存储中更能缓解 XSS。这种方法也可以免受 CSRF 攻击，因为即使表单提交攻击可以进行 /refresh_token API 调用，攻击者也无法获取返回的新 JWT 令牌值。

第二篇文章也说了类似的话：

尽管提交的表单/refresh_token将起作用并且将返回新的访问令牌，但如果攻击者使用 HTML 表单，则他们无法读取响应

我正在努力了解这将如何防止 CSRF 攻击，因为我在想以下内容：

1. 从另一个域向用户发出的请求/refresh token将向用户返回新的 JWT 令牌。我假设它存储在 HttpOnly cookie 中（如第一篇文章中所做的那样）
2. 由于 CSRF 不涉及任何 javascript 注入，且 cookie 为 httpOnly，因此攻击者无法读取新 JWT 令牌的值。
3. 但是，如果 JWT 令牌再次存储在 cookie 中，CSRF 攻击者肯定可以使用这个新 cookie 以及新的 JWT 令牌发送另一个请求吗？

如果我的理解是正确的，我正在努力了解如何使用刷新令牌来防止 CSRF 攻击。有人可以准确解释为什么刷新令牌可以防止 CSRF 攻击，以及为什么 CSRF 攻击者不能只使用用户收到的新 JWT 进行未来的攻击吗？

在我看来，真正防止 CSRF 攻击的方法是使用 SameSite cookie，或者使用某种防伪造令牌。

Answer 1

新的 jwt 不会作为 cookie 从身份提供者返回。这没有多大意义，因为不同来源的客户端将无法阅读它。相反，令牌会在响应正文中传递，甚至是 url（在这种情况下通常不是令牌，但我们不要深入研究）。

因此，idp 有其 httpOnly cookie 来验证用户身份，以某种非 cookie 的方式发出新令牌，并且客户端将相应来源（而不是 idp）的令牌存储在本地存储中。这样，对资源服务器的任何调用都不会受到 csrf 的攻击，因为需要从本地存储显式添加令牌。Attacker.com 可以调用 idp 来颁发新的令牌（“csrf”），但由于同源策略，attacker.com 将无法访问该令牌，因此不可利用。

请注意，即使新令牌作为 idp 的 cookie 返回并由客户端从那里读取，它仍然可以，因为 idp 不会对该令牌执行任何操作，并且资源服务器（~api）不会自动接收它。