如何以及在何处安全地存储访问令牌答案

【问题标题】：How and where to store access token securely如何以及在何处安全地存储访问令牌
【发布时间】：2016-03-08 15:17:55
【问题描述】：

我知道这个问题已经被问过很多次，但坦率地说，我还没有看到满足我所拥有标准的答案。

所以我有一个 ASP.NET WEB API，它在提供用户/密码时发出访问令牌 (JWT)。目前请求来自 SPA 应用程序。我遇到的问题是存储访问令牌，以便它可以从 JavaScript 重新发送到 API。到目前为止，似乎有 2 个常用的建议选项

但是这些都不是真正安全的，因为它们没有受到 XSS 和 CSRF 的保护。最重要的是，它使令牌易于访问。

您有什么建议吗？

【问题讨论】：

这里是good resource，如果你还没有看过/读过的话。
谢谢我已经看到了。我只是不明白它是如何回答问题的））我仍然可以获得访问令牌并将请求直接发送到 API
XSS and C/XSRF上的具体部分？但是，它不会保护您的 API 免受 curl 之类的直接请求 - 尽管我个人不确定（并且想知道）如何完成攻击（假设反 xss 已到位） - 换句话说，一些 else 将如何获取该令牌（假设您可以访问 您自己的令牌）？
@EdSF 如果我设置 httpOnly cookie 我将如何从 JavaSript 获取值？
我认为该部分表示令牌很容易受到 XSS 如果您的应用程序是/首先（缓解因素是 iat 和 exp）

【解决方案1】：

网上商店易受 XSS 攻击。如果不是 HTTPONLY，Cookie 很容易受到 XSS 攻击。 Cookie 在非 STRICT 时很容易受到 CSRF 的攻击，即使它是 HTTPONLY。

所以我认为我们可以将访问令牌存储在内存中。问题是页面刷新之间没有持久性。因此，为了持久性，我们可以将刷新令牌存储在 Web 存储或 cookie 中，当我们没有访问令牌时，我们可以通过刷新令牌静默获取一个新令牌。

使用身份服务器时，刷新令牌对任何未经授权的客户端都没有任何用处。

因此，如果他们 XSS 并使用刷新令牌 cookie 窃取刷新令牌或 CSRF，他们就无法冒充用户或获取访问令牌。

【讨论】：