Questions:
-
依靠ASP.Net Core API的Angular应用程序的默认ASP.NET身份cookie和防伪机制是否安全？
-
在简单的部署方案中，标准ASP.NET身份生成承载令牌（JWT）会带来实实在在的好处吗？如果是这样，管理过期的最佳方法是什么？
-
对于SPA应用程序，OIDC是否比ASP.NET身份更安全？
即使用IdentityServer会更安全吗？
Background:
我正在使用ASP.Net Core API构建一个Angular应用程序，我希望使用现代最佳实践来保护它 . 我希望用户能够通过OIDC登录，但我不需要OIDC服务器来管理对多个应用程序/服务的访问（它只是一个应用程序 . ）我想要最简单，最安全的解决方案 .
我知道我可以在SPA应用程序中编写代码以针对我想支持的每个提供程序启动OIDC，但使用ASP.Net Identity内置的外部提供程序支持似乎更简单 . 经过身份验证后，我不清楚应用程序应如何保持登录令牌/会话对XSS和CSRF的安全性 .
ASP.Net Identity 默认使用cookie和防伪标记 . 这适合JavaScript应用吗？内置的Angular对XSRF和这个csrf tutorial的支持似乎表明它是一种标准做法 . Cookie容易受到XSS的攻击，但CSP和Angular可以帮助缓解这种情况 .
IdentityServer 作者建议OIDC访问令牌应与CSP一起存储在sessionStorage中 . （Blogged here＆questioned here . ）然而，这些令牌通常是短暂的，所以我怀疑有不同的权衡 . 我的理解是，刷新OIDC访问令牌可能无论如何都要访问OIDC服务器，这是真的吗？
为什么IdentityServer和JWT似乎比ASP.Net Identity更受欢迎？人们真的需要STS或令牌的好处来支持移动应用程序，还是技术上有趣？
Additional Considerations:
-
如果我想将身份与数据API划分为单独的ASP.Net核心项目（但仍然将它们部署在同一个域/服务器上）会改变上述问题的答案吗？
-
OIDC是否提供任何其他福利？ （鉴于我只有一个API . ）签名更容易/更好吗？