如何保护刷新令牌？

Question

我正在使用JWTs为我的应用程序验证用户身份。当用户登录时，他们将获得一个访问令牌和一个刷新令牌。为了保证刷新令牌的安全，我不将其存储在客户端，而是将其与他们的帐户一起保存在后端，这样就不容易访问了。虽然我对刷新令牌的安全性感到困惑，但当我阅读关于如何使用刷新令牌的在线资源时，以下是我理解的逻辑：

1. 身份验证
2. 将访问令牌+刷新令牌存储在某个位置（在我的示例中，访问令牌位于前端，刷新令牌位于后端）
3. 执行api请求时，在api端验证访问令牌
4. 如果访问令牌过期，使用刷新令牌生成新的访问令牌+新的刷新令牌，将访问令牌发送回客户端
5. 像以前一样存储令牌...并重复

我担心的安全问题是，如果其他人（黑客）掌握了访问令牌，并用它向api发送请求，如果令牌过期，api将使用刷新令牌获取新的访问令牌+新的刷新令牌，并至少将访问令牌返回给黑客。

这篇文章我读了5-6遍，也读了几遍，还有一些关于这个主题的其他文章，他们都是这样说的

确保安全地存储refresh令牌，因为它的寿命很长，access_token的寿命很短，所以没什么大不了的

但是根据我上面描述的流程，如果访问令牌是短命的也没关系，刷新令牌将用于获得新的访问令牌并永远拥有访问权。

是不是我漏了什么？如果黑客掌握了过期的访问令牌，api如何知道谁在发送请求？它仍然会使用刷新令牌发送一个新的。我应该以某种方式验证是谁在发送请求吗？

因此，我理解当请求新的访问令牌时，我需要发送刷新令牌、客户端ID和客户端机密。我遇到的问题是，像前面一样，黑客可以向我的API服务器发送一个请求，服务器从黑客那里得到劫持的访问令牌，它会看到它过期了，所以它会将刷新令牌以及ClientID/Client秘密（它们被存储为环境变量）发送给Auth API，并返回一个新的访问令牌/刷新令牌，这又回到了同样的问题上。

更新2

关于这个主题的一些有趣的问题：

null

根据第二个问题和答案，刷新令牌似乎并不是一种更安全的维护访问的方法，只是它更容易检测黑客，因为身份验证/刷新令牌不断被请求并使对方的令牌无效。问题是，只有当两个用户同时尝试访问资源时，才会发生这种情况--如果黑客在给定的时间段内恰好处于活动状态，那么他将可以无限制地访问原始用户的数据，直到原始用户尝试使用应用程序并访问受保护的资源

Answer 1

基本上，在基于浏览器的应用程序中使用刷新令牌似乎是个坏主意。刷新令牌用于移动应用程序，其中刷新令牌可以安全地存储在手机上--手机有某种安全的存储机制，而浏览器没有。

可以对这个答案进行改进。虽然我个人仍然认为在浏览器存储中存储访问令牌或刷新令牌都是不安全的（在阅读了许多关于这个主题的文章之后，尽管许多仍然这样做），但在localstorage中使用一个短期访问令牌+内存中的刷新令牌可以极大地改善用户体验。这样，只要用户不进行硬刷新，或者不离开网站/webapp，他们就会被无限期地登录。