为什么我不能在浏览器中存储 oauth 刷新令牌？答案

【问题标题】：Why can't I store an oauth refresh token in the browser?为什么我不能在浏览器中存储 oauth 刷新令牌？
【发布时间】：2017-03-11 14:49:46
【问题描述】：

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

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

我认为没关系，因为：

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

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

【问题讨论】：

标签： security authentication web-applications oauth2 refresh-token

【解决方案1】：

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

将令牌存储在 httpOnly 和安全 cookie 中使其几乎等同于会话 id，并且在这方面它的安全性也是相同的（显然其他方面可能不同）。

【讨论】：

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

【解决方案2】：

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

Auth0 网站有一些关于它的建议：

我们建议使用 Auth0 Single Page App SDK。 Auth0 SPA SDK 为您处理令牌存储、会话管理和其他详细信息。

更多详情请点击here。

【讨论】：