我一直在审查我们应该如何在我们的浏览器应用程序（SPA）中处理OAuth身份验证，并且有大量文章使得它真的让人感到困惑......我真的错过了一些具体和最佳实践非常简单的设置指南。
我们有这个使用IdSvr3发布的令牌保护的ASP.NET Web API 2。到现在为止还挺好。适用于本机客户端和服务器应用程序。
现在浏览器的内容......查看JavaScriptImplicitClient这样的示例，它使用oidc-client-js库来使用隐式流检索令牌。令牌存储在浏览器中，可以使用JavaScript访问，并且可以通过XSS攻击进行打开。 为了避免这种情况，建议指示将令牌存储在cookie中，然后设置机制以防止CSRF攻击。
看起来很简单，但是什么设置了这个cookie？
是IdSvr吗？没有意义，因为它是需要cookie的API。
是API吗？在Implicit Flow登录期间，用户是否会重定向到设置会话的API，然后使用Set-Cookie标头将用户重定向回SPA？然后，cookie将在后续请求中出现在API中。
第三种解决方案？有些人提到创建第二个“API”来代理对“真实”API的请求，但设置了auth标头。
您是否有任何此类设置的样本，或者您是否可以提供一些有关如何进行此操作的提示？
答案 0 :(得分：1)
就个人而言，大多数情况下由于XSS而避免使用令牌的Web存储似乎会加剧一些。有一个重要的问题，如果您的应用程序容易受到XSS攻击，那么此漏洞的影响会因为您泄漏令牌而显着增加，或者即使您没有在那里存储令牌而且您已经完全失败了麻烦的类型。
我比较了一些在Web浏览器应用程序中存储访问令牌的方法的优缺点，您可以check in this answer to a related question。
最后，每个案例最终都有自己的细节，这可能会在一种方法与另一种方法（cookie或网络存储）之间取得平衡。只是不要从一开始就忽略任何选项，并根据您的要求查看所有选项。
我敢打赌，有些实现将它们存储在仅HTTP的cookie中，以避免Web存储的XSS问题，然后最终使用面对XSS易受攻击的CSRF缓解策略