#1 楼
您可以通过两种方式在浏览器中保存身份验证信息：Cookies
HTML5 Web存储
在每种情况下，您都必须相信正确实现了浏览器，并且网站A无法以某种方式访问网站B的身份验证信息。从这个意义上讲，这两种存储机制都同样安全。但是，在如何使用它们方面可能会出现问题。
如果使用cookie：
浏览器将在每次请求时自动向API发送身份验证信息。只要知道它正在发生，这就很方便。
您必须记住CSRF是一件事，并加以处理。
如果您使用HTML5 Web存储：
您必须编写Javascript来精确管理将什么身份验证信息发送到API。
人们关心的一个实际差异是，使用cookie时，您必须担心CSRF。为了正确处理CSRF，您需要一个附加的“同步器令牌”。
多合一Web框架（例如Grails，Rails，可能是asp.net）通常提供启用CSRF保护并自动添加同步器的简便方法。用户界面中的令牌内容。但是，如果要使用仅客户端的Web框架（例如AngularJS或BackboneJS）编写UI，则必须编写一些Javascript来管理同步器令牌。因此，在这种情况下，您最好还是使用HTML5 Web存储方法，而只担心一个令牌。
评论
您也可以将令牌分为两部分（请参见jcbaey.com/…）。仅限HTTP的Cookie中的一部分，位于本地存储中的一部分。这样，CSRF是不可能的，并且无法通过XSS进行窃取。
–弗朗兹·德施勒（Franz Deschler）
20年11月9日，11：43
#2 楼
保护访问令牌的最佳方法是根本不将其存储在客户端。这是如何工作的？好了，在生成访问令牌时，请生成其他一些加密安全的PRNG（您将其映射到服务器上的访问令牌），然后将其映射到用户会话ID，然后将其返回给客户端。
这将减少攻击范围，因为您现在返回的是绑定到会话的令牌，并且需要两个令牌才能授权令牌。当会话到期时，令牌自然也会失效，并且用户将被强制重新认证，从而生成新的访问令牌。
它仍然不是100％安全的，但是，您需要权衡一下在用户会话中发生类似情况的可能性。基于此，您可以调整会话/令牌的到期时间以适应情况，尽管您还需要注意可用性-您不想在5分钟后到期，因为必须不断重新登录可能会很乏味（也许可以，取决于应用程序的类型。
评论
感谢您的遮阳篷，但我需要在AJAX API调用的标头中包含令牌，因此我需要在JavaScript中可访问的完整令牌。
– jfamvg
2015年2月3日，12：11
@jfamvg我不是建议您不要在客户端上存储令牌，而是要不要在此处存储私有访问令牌。生成一个公共令牌并将其发送。
–詹姆斯
15年2月3日，15：43
我不理解公共令牌和私有令牌之间的区别。在OAuth中，令牌是令牌。如果您可以使用它向WebAPI发出请求，那么您在这里提供什么保护？您是否假设令牌中有一些信息需要保护？如果您使用的是Katana的OAuth提供程序，它将通过加密组成令牌的声明来处理。
– Ed Greaves
16 Jun 14 '16：00
但是，访问令牌不只是密码安全的随机性吗？
–拉扎尔（LazarLjubenović）
18年11月6日15:09
@LazarLjubenović很好，这完全取决于令牌的生成方式，在使用OAuth等服务时，是的，您可以确保返回的令牌可以安全地存储在客户端上（一定程度上）。
–詹姆斯
18年11月6日在15:54
#3 楼
ARMOR专为满足此要求而设计。防伪令牌可以存储在您认为合适的UI上的任何位置。该库配备了一个自定义JavaScript组件，该组件从UI中提取令牌并将其自动包含在AJAX标头中。这是一个有关此主题的教程，这是GitHub存储库。
#4 楼
我将令牌存储在带有以下三个标志的cookie中：1。安全：通过https
2传输。 HttpOnly：客户端JS无法读取它（XSS保护）
3。 SameSite（宽松或严格）：CSRF保护
通过这种方式，您可以不受XSS和CSRF的影响。
您只需要注意SameSite，因为它相对较新并且最近才得到4种主要浏览器（Chrome，FF，Safari，Edge）的支持。
请参阅：https://caniuse.com /＃feat = same-site-cookie-attribute
有关Cookie强化的更多信息，请参见
https://odino.org/security-hardening-http-cookies/
#5 楼
Alex的博客必须提供丰富的信息。每当有人在Web应用程序的单个页面中实现OAuth时，服务器就会死亡。停止种族灭绝！使用服务器端代理！立即行动！
https://github.com/alexbilbie/alexbilbie.github.com/blob/master/_posts/2014-11-11-oauth-and-javascript.md
评论
那篇文章中提出的解决方案似乎无济于事。假设攻击者可以访问用户的客户端状态（令牌，Cookie等），则攻击者可以简单地将相同请求发送到代理服务器：GET / ajax / resource / 123 HTTP / 1.1 Cookie：<带有令牌的加密Cookie>主持人：example.com。如果他的意思是“使用cookie代替本地存储”，那么他应该说得更清楚。
–BudgieInWA
15年11月18日在2:40
那篇文章没有道理。建议的代理服务器如何区分“真实用户”和“攻击者”？所有http请求都可以被伪造。 CSRF只需要一个额外的http调用即可获得csrf令牌。唯一解决作者问题的方法是验证码和速率限制。请解释我是否错。
–cnvzmxcvmcx
16年8月7日在17:56
#6 楼
您需要在每个请求集中将令牌发送到服务器。因此，将其存储在Cookie或html 5存储中无关紧要。两者都是安全的存储，访问客户端计算机的eveyone仍然可以访问令牌。但是我建议不要在服务器上的cookie中使用提交的令牌，以防止CSRF攻击。我认为最好在需要时在每个请求中手动包含令牌。
使用cookie还会使请求标头变大，这是不合适的。
评论
这是矛盾的。如何在每个请求中包含令牌，同时又不将其包含在Cookie：HTTP标头中？好的，您可以创建自己的X-Something：标头，但这可能会更糟，因为您需要维护用于存储标头内容的代码。
–grochmal
16 Dec 16'1:33
你是对的。对于我的Web应用程序来说，这是可能的，因为我始终只是通过ajax请求调用api调用。因此，我的方法无法在其他Senarios中实现。
– Mohammad Nikravan
16 Dec 16'在9:18
评论
我认为使用SSL证书应该可以完成您的工作，这里有出版物说明了它们的用法和作用：rfc-base.org/rfc-6101.html。SSL将以什么方式帮助保护存储在客户端上的令牌？
ceur-ws.org/Vol-313/paper9.pdf请阅读此内容。这样一来，在支持客户的过程中就会遇到问题。
会话Cookie。不要想太多，这些东西是有原因的。
“我认为...”当世界其他地区依靠Cookie来存储此类令牌时，也许您应该解释一下您的想法，以便我们可能都可以更好地了解情况并有机会提出解决您的问题的解决方案？