为什么在身份验证期间使用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攻击。第一条规定：

刷新令牌由auth服务器作为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 it httpOnly，如果JWT令牌再次存储在cookie中，攻击者就无法读取新JWT
3. 的值，当然，CSRF攻击者可以使用这个新的
4. 发送另一个请求，其中包含新的JWT令牌sinde

。

如果我的理解是正确的，我正在努力了解如何使用刷新令牌来防止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)也不会自动接收它。