为了使用JWT保护REST API，根据某些资料（如本指南和此问题），JWT可以存储在任一localStorage中或Cookies中。根据我的理解：
因此，基于以上前提，最好将JWT存储在Cookies中。在对服务器的每个请求中，都将使用Cookie方案从Cookie中读取JWT并将其添加到Authorization标头中。然后，服务器可以验证请求标头中的JWT（与从Cookie中读取JWT相反）。
我的理解正确吗？如果是这样，上述方法是否涉及安全性？还是实际上我们可以首先使用localStorage逃脱？
Answers:
我喜欢@ pkid169所说的文章中提到的XSRF Double Submit Cookies方法，但是有一件事情没有告诉您。您仍然没有受到XSS的保护，因为攻击者可以执行的操作是注入脚本，该脚本读取CSRF cookie（不是HttpOnly），然后使用此CSRF令牌向您的API端点之一发出请求，并自动发送JWT cookie。
因此，实际上您仍然容易受到XSS的攻击，只是攻击者无法窃取您的JWT令牌供以后使用，但攻击者仍然可以使用XSS代表您的用户发出请求。
无论是将JWT存储在localStorage中，还是将XSRF令牌存储在非仅HTTP的cookie中，XSS都可以轻松地将两者捕获。甚至您的HttpOnly cookie中的JWT都可以通过高级XSS攻击来抢夺。
因此，除了使用Double Submit Cookies方法外，您还必须始终遵循针对XSS的最佳做法，包括转义内容。这意味着删除所有可能导致浏览器执行您不希望执行的操作的可执行代码。通常，这意味着删除// <！[CDATA [标签和HTML属性，这些属性会导致对JavaScript进行评估。
Html.AntiForgeryToken()在ASP.NET MVC中，默认实现使用CSRF令牌的HttpOnly cookie。我认为您仍然容易受到某些XSS的影响，但我认为这值得一提。
来自Stormpath的及时发布已经阐明了我的观点并回答了我的问题。
将JWT存储在cookie中，然后像我提到的那样在每个请求上将JWT传递到Authorization标头中，或者如文章所述，依靠后端来防止CSRF（例如，xsrfToken在Angular中使用）。
相反，您可以在登录时交付两个令牌：访问令牌和刷新令牌。访问令牌应存储在Javascript内存中，刷新令牌应存储在HttpOnly Cookie中。刷新令牌仅用于创建新的访问令牌，仅此而已。
当用户打开新选项卡或在站点刷新时，您需要基于存储在Cookie中的刷新令牌执行请求以创建新的访问令牌。
我也强烈建议您阅读以下文章：https : //hasura.io/blog/best-practices-of-using-jwt-with-graphql/
secure，samesite: strict，http-only？
为了帮助防止利用现有Cookie的CSRF攻击，您可以使用SameSite指令设置Cookie 。将其设置为lax或strict。
这仍然是草案，截至2019年，当前所有的浏览器均未完全支持它，但是取决于数据的敏感性和/或您对用户使用的浏览器的控制，这可能是一个可行的选择。将指令设置为SameSite=lax会允许“使用'safe'... HTTP方法的顶级导航”。