在基于 Web 的应用程序中，在哪里正确且安全地存储 JWT 令牌？

Question

我熟悉 Web 存储 API 和 cookie，但我不知道存储身份验证令牌的最安全方法是什么。我想知道这是否会破坏任何第三方库。

我想要一份可用方法的详尽列表，其中包括每种方法的优缺点，以及最重要的最佳方法（如果有的话）。

Answer 1

在哪里存储 JWT

通过基于令牌的身份验证，您可以选择存储 JWT 的位置。我们强烈建议您将令牌存储在本地存储/会话存储或 cookie 中。

Web 存储（本地存储/会话存储）

通常，JWT 放置在浏览器本地存储中，这对于大多数用例都很有效。

使用用户名和密码登录用户时，响应正文包含

access_token JWT

。然后您需要在客户端代码中处理此响应。然后可以将该令牌存储在 localStorage 或 sessionStorage 中。

单击此处查看使用 sessionStorage 的示例

localStorage

和

sessionStorage

都延伸

Storage

。它们之间唯一的区别是数据的持久性：

localStorage

- 数据将持续存在，直到明确删除为止。所做的更改将被保存并可供当前和将来访问该网站时使用。

sessionStorage

- 所做的更改将被保存并可用于当前页面以及将来在同一窗口上访问该网站。窗口关闭后，存储将被删除。

网络存储的缺点

• 与 cookie 不同，本地存储被沙箱到特定域，任何其他域（包括子域）都无法访问其数据。
• Web 存储可通过同一域上的 JavaScript 进行访问，因此您网站上运行的任何 JavaScript 都可以访问 Web 存储，因此可能容易受到跨站点脚本 (XSS) 攻击。
• 开发人员必须确保 JWT 始终通过 HTTPS 而不是 HTTP 发送。

使用 Cookie

您还可以使用cookie来存储JWT。设置 cookie 的确切方法取决于您使用的客户端语言。

有不同的选项来控制 cookie 的生命周期：

• 浏览器关闭后 Cookie 会被销毁（会话 Cookie）。
• 实现服务器端检查（通常由正在使用的 Web 框架为您完成），并且您可以实现过期或滑动窗口过期。
• Cookie 可以持久保存（浏览器关闭后不会被销毁），并且有过期时间。
• Cookie 可以由 JavaScript 和服务器端代码读取，或者如果设置了

  httpOnly

  标志，则只能由服务器端读取。

Cookie 的缺点

• cookie 的最大大小仅为 4kb，因此如果您有许多声明附加到令牌，这可能会出现问题。
• Cookie 可能容易受到跨站点请求伪造（CSRF 或 XSRF）攻击。当恶意网站导致用户的 Web 浏览器在用户当前经过身份验证的受信任网站上执行不需要的操作时，就会发生这种类型的攻击。这是对浏览器处理 cookie 方式的利用。使用 Web 应用程序框架的 CSRF 保护使 cookie 成为存储 JWT 的安全选项。通过检查 HTTP

  Referer

  和

  Origin

  标头也可以部分阻止 CSRF。
• 如果应用程序需要跨域访问，则可能很难实现。 Cookie 具有其他属性（域/路径），可以修改这些属性以允许您指定允许将 Cookie 发送到的位置。

原文：https://auth0.com/docs/security/store-tokens#how-to-implement

Answer 2

1. JWT 永远不应该存储在本地存储中
2. 事实上，它们甚至不应该存储在您的 cookie 中，除非您能够实施非常严格的 CSRF 保护

看看这个以获得动力

• JWT 作为 id_token 就像您的用户凭证
• JWT 作为 access_token 就像您的会话令牌

最安全的选项是内存中。 查看此内容进行深入研究

Answer 3

如果@dmitry-s解决方案仍然不适合您，请考虑将您的访问令牌存储在Web Worker中，如本文建议。

Web Worker 有自己的线程，并且不向恶意第三方或 XSS 脚本提供获取令牌的机会（像 localStorage 和 sessionStorage 那样）。但请记住，您必须设计前端代码与 Web Worker 通信的方式，才能安全地发出 API 请求。

它在现代浏览器中广泛传播，但您可以在此处检查它是否适合您的用户。