选择存储更多的是权衡，而不是试图找到明确的最佳选择。让我们来看看几个选项：

选项 1 - 网络存储（localStorage或sessionStorage）

优点

• 浏览器不会自动将 Web 存储中的任何内容包含到 HTTP 请求中，使其不易受到 CSRF 的攻击
• 只能由在创建数据的完全相同域中运行的 Javascript 访问
• 允许使用语义最正确的方法在 HTTP（Authorization带有Bearer方案的标头）中传递令牌身份验证凭据
• 挑选应该包含身份验证的请求非常容易

缺点

• 无法被在创建数据的子域中运行的 Javascript 访问（写入的值example.com不能被读取sub.example.com）
• ⚠️ 易受 XSS 攻击
• 为了执行经过身份验证的请求，您只能使用允许您自定义请求的浏览器/库 API（在Authorization标头中传递令牌）

用法

在执行请求时，您可以利用浏览器localStorage或sessionStorageAPI 来存储和检索令牌。

localStorage.setItem('token', 'asY-x34SfYPk'); // write
console.log(localStorage.getItem('token')); // read

选项 2 - 仅 HTTP cookie

优点

• 这是不容易受到XSS
• 浏览器会自动在任何符合 cookie 规范（域、路径和生存期）的请求中包含令牌
• cookie 可以在顶级域中创建并用于子域执行的请求中

缺点

• ⚠️ 易受 CSRF 攻击
• 您需要注意并始终考虑子域中 cookie 的可能用途
• Cherry 选择应该包含 cookie 的请求是可行的，但更麻烦
• 您可能（仍然）遇到一些问题，浏览器处理 cookie 的方式略有不同
• ⚠️ 如果你不小心你可能会实施一个容易受到 XSS 攻击的 CSRF 缓解策略
• 服务器端需要验证 cookie 进行身份验证，而不是更合适的Authorizationheader

用法

您不需要在客户端做任何事情，因为浏览器会自动为您处理事情。

选项 3 -_{服务器端忽略}Javascript 可访问 cookie

优点

• 它不容易受到 CSRF 的影响（因为它被服务器忽略了）
• cookie 可以在顶级域中创建并用于子域执行的请求中
• 允许使用语义最正确的方法在 HTTP（Authorization带有Bearer方案的标头）中传递令牌身份验证凭据
• 挑选应该包含身份验证的请求有点容易

缺点

• ⚠️ 易受 XSS 攻击
• 如果您不小心设置 cookie 的路径，那么浏览器会自动将 cookie 包含在请求中，这将增加不必要的开销
• 为了执行经过身份验证的请求，您只能使用允许您自定义请求的浏览器/库 API（在Authorization标头中传递令牌）

用法

document.cookie在执行请求时，您可以利用浏览器API 来存储和检索令牌。此 API 不像 Web 存储（您获得所有 cookie）那样细粒度，因此您需要额外的工作来解析您需要的信息。

document.cookie = "token=asY-x34SfYPk"; // write
console.log(document.cookie); // read

补充笔记

这似乎是一个奇怪的选择，但它确实有一个很好的好处，即您可以将存储用于顶级域和所有子域，这是 Web 存储不会给您的。然而，它的实现更加复杂。

结论 - 最后的笔记

我对最常见场景的建议是使用 Option 1，主要是因为：

• 如果您创建一个 Web 应用程序，您需要处理 XSS；始终，独立于您存储令牌的位置
• 如果您不使用基于 cookie 的身份验证 CSRF 甚至不应该出现在您的雷达上，因此无需担心

另请注意，基于 cookie 的选项也有很大不同，因为选项 3 cookie 纯粹用作存储机制，因此它几乎就像是客户端的实现细节。然而，选项 2 意味着更传统的处理身份验证的方式；要进一步阅读 cookie 与令牌的相关内容，您可能会发现这篇文章很有趣：Cookie 与令牌：权威指南。

最后，没有一个选项提到它，但使用 HTTPS 当然是强制性的，这意味着应该适当地创建 cookie 以考虑到这一点。

[编辑] 这个答案是公认的，但是 João Angelo 的回复更详细，应该考虑。有一点需要注意，并且由于自 2016 年 11 月以来安全实践发生了变化，因此应实施选项 2 以支持选项 1。

看这个网站：https : //auth0.com/blog/2014/01/07/angularjs-authentication-with-cookies-vs-token/

如果您想存储它们，您应该使用 localStorage 或 sessionStorage（如果可用）或 cookie。您还应该使用 Authorization 标头，但不要使用 Basic 方案，而是使用 Bearer 一：

curl -v -X POST -H "Authorization: Bearer YOUR_JWT_HERE"

使用 JS，您可以使用以下代码：

<script type='text/javascript'>
// define vars
var url = 'https://...';

// ajax call
$.ajax({
    url: url,
    dataType : 'jsonp',
    beforeSend : function(xhr) {
      // set header if JWT is set
      if ($window.sessionStorage.token) {
          xhr.setRequestHeader("Authorization", "Bearer " +  $window.sessionStorage.token);
      }

    },
    error : function() {
      // error handler
    },
    success: function(data) {
        // success handler
    }
});
</script>

这篇博文对浏览器存储与 cookie 进行了很好的并排比较，并解决了每种情况下的所有潜在攻击。https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage/

简短的答案/剧透：cookies 并在 jwt.js 中添加 xsrf 令牌。博文中有详细解释。

截至2021和事物发展有点引进的的SameSite：国际机场/严格的选项饼干上最nowdays浏览器

因此，要详细说明 João Angelo 的回答，我想说现在最安全的方法是：

使用以下选项将JWT存储在 cookie 中

• 仅Http
• 安全的
• SameSite：松散或严格

这将同时避免 XSS 和 CSRF

你应该永远，永远不要在内存之外存储 JWT。

如果您想在长时间会话期间保留 JWT（比如 1 小时，当令牌只有 15 分钟到期时），请在令牌即将到期时再次在后台静默记录用户。

如果要跨会话保留 JWT，则应使用刷新令牌。顺便说一句，其中大部分时间也用于上述目的。您应该将其存储在 HttpOnly cookie 中（好吧，更准确地说，服务器集是通过 Set-Cookie 标头，前端调用 /refresh_token API 端点。）

顺便说一句，刷新令牌是最不坏的；为了补充它，您应该确保遵循最佳实践来缓解 XSS。

localStorage、sessionStorage 和 cookie 都有其漏洞。

这是我读过的关于 JWT 的最佳指南：https ://blog.hasura.io/best-practices-of-using-jwt-with-graphql/