Security 为什么可以'；我是否在浏览器中存储oauth刷新令牌？

我想在浏览器中存储oauth刷新令牌。我希望将其存储在那里的原因是，应用程序可以刷新访问令牌，并允许用户不间断地继续他们的会话。我还希望消除服务器上存储令牌的任何缓存的需要，从而使其成为有状态的

我被告知在浏览器中存储刷新令牌是错误的，因为它不安全

我觉得没关系，因为：

令牌将存储在HTTP5、安全会话Cookie中，因此它们不应易受XSS或中间人攻击的影响，当用户关闭会话时，它们将被丢弃。
• 与服务器的所有通信都通过HTTPS完成
• 如果检测到可疑活动，刷新令牌可能会失效
• 最重要的是，除非知道只有服务器才能知道的客户端秘密，否则不能使用刷新令牌

我认为应该没问题是不是错了？请解释原因

将令牌存储在httpOnly中，安全cookie可能是实现安全性的最好方法。有时问题是，由于其他（非安全）原因，httpOnly cookie不够好，因为Javascript显然没有访问权限（这就是重点）。因此，人们有时希望将令牌存储在其他浏览器存储中，比如localStorage，或者更好一些，存储在JavaScript对象中，这两种对象的安全性都明显低于httpOnly cookie（但对于某些应用程序来说仍然足够好）

---

将令牌存储在httpOnly和secure cookie中，使其与会话id非常等效，在这方面，其安全性也将相同（显然其他方面可能不同）。

实际上，您可以将令牌存储在浏览器中，您只需知道哪些存储机制更适合您的解决方案。例如，在本地存储中是最不安全的，如果您的后端和单页应用程序位于同一个域中，我建议您使用cookies

Auth0网站对此有一些建议：

我们建议使用Auth0单页应用程序SDK。Auth0 SPA SDK 为您处理令牌存储、会话管理和其他详细信息

---

有关更多详细信息，请单击。

，cookie将与后续请求一起自动发送？如果是，那么，如果有人能够注入恶意js并开始发出请求，他将能够使用cookie。虽然不能直接显式读取。是的，使用xss，只要有xss机会，他就可以使用cookie，但这需要用户交互，而不是拥有令牌并从另一个（攻击者的）客户端发送。当您将cookie中存储的令牌标记为httponly时，xss攻击会减轻。对于f yes，那么，如果有人能够注入恶意js并开始发出请求，那么您可以使用CSRF令牌来验证请求。它可以放在JWT令牌itslef中，以验证服务器端的请求。