在以API为中心的应用程序上使用JWT而不是Cookie时有很多优点，我知道您可以在通过浏览器访问应用程序时将令牌存储在sessionStorage上。 您可以在JS代码上设置拦截器，以便在GET请求的Authorization标头上注入JWT令牌 - 只要这些GET请求来自验证用户的相同代码。
但是，当用户通过身份验证后会发生什么，然后打开新选项卡并尝试访问应用程序/站点的其他受限区域（甚至同一区域）？在这种情况下，没有拦截器在新选项卡上的Authorization标头上注入令牌。我想服务器将收到GET请求，在Authorization标头上查找JWT令牌，但不会找到它，拒绝请求。
当您使用Cookie时，它们始终由浏览器本地发送，您不必担心新标签和身份验证。
当用户在第一个标签中进行身份验证时，是否有办法在浏览器上为域全局设置Authorization标头？如果有的话，这个问题的常用解决方案是什么？
答案 0 :(得分：5)
在没有正确凭据（如JWT）的情况下访问受保护的URL时，浏览器将被重定向到特定端点（例如，在授权服务器上），在那里它可以获得新的JWT。
例如在OpenID Connect隐式流程中发生这种情况：http://openid.net/specs/openid-connect-implicit-1_0.html
但也可以将JWT存储在cookie中。这不是呈现JWT的标准化方式，因此它将特定于您的客户端/浏览器和受保护的应用程序。
答案 1 :(得分：1)
由于新发现，我决定添加此问题的更新。我不会改变原来的答案。
首先，根据我对原始答案的评论：
我最终使用cookie来保存JWT，但它是由客户端设置的 首次验证后使用fieldNames。我的 服务器代码按以下顺序检查请求中的JWT：header， 身体，饼干。因此，每当用户打开新选项卡时，本地设置 使用cookie。其他页内请求会在标头中注入JWT。 这样，该操作是面向API的，回退到cookie中 最后一个案例。
但是，我也担心浏览器上生成的cookie的安全性。这是因为，由于它是由客户端JavaScript生成的，因此您无法使用HttpOnly，而是为XSS打开它。
<强>解决方案
由于我正在使用Sails，我只是决定在服务器上使用JWT令牌创建一个cookie，并使用响应发送它，该响应还包含正文中对象上的JWT令牌。
github.com/js-cookie/js-cookie
res.cookie（）
设置一个cookie，其中包含要发送的名称（名称）和值（值） 回应。
ave此cookie不需要在服务器上启用会话，因此它实现了使用JWT的“无会话”优势。
如果客户端是浏览器，它将在后续请求中存储和重用该令牌，包括在HttpOnly cookie的帮助下在新选项卡上。
如果是另一种类型的客户端，它在响应主体上有JWT令牌。