嗨，我正在为Intranet中的所有应用程序构建集中式身份验证结构。
我尝试使用Jwt Web Api。
我已经尝试过Identity Server 4 OpenConnect
现在我从Microsoft文档中发现了Cookie共享
https://docs.microsoft.com/en-us/aspnet/core/security/cookie-sharing?view=aspnetcore-2.2
即使已经阅读了很多文章，我也无法决定我应该执行哪个文章。
cookie共享听起来非常简单，我下载了示例，并且可以直接使用。
Identity Server 4样本都有一些我无法运行的问题。诸如注销之类的某些功能将不起作用，或者仅在一端起作用。
Jwt Web Api并不是很难实现，但是仍然需要一些思想者来从令牌中获取声明，然后实现令牌刷新。
我刚刚发现了Cookie共享，但我仍然愿意接受更多选择或利弊。
我也听说过OWIN，但仍然不清楚它是什么
答案 0 :(得分：2)
AFAIK
Cookie共享
如果所有应用程序都在Intranet上并且全部使用点网堆栈制作。利用共享cookie是很有意义的。我以前曾成功使用此策略实施SSO，主要登录名是一个旧的Web表单应用程序，它将授权一个dotnet核心应用程序。
优点：您正在使用Microsoft堆栈，易于设置。
缺点：您被锁定为使用Microsoft堆栈。如果要与本机/ js应用程序一起使用，则失败。
IdentityServer4
已经对该库进行了很多试验，它是OAuth2和OpenIdConnect协议的抽象，本质上是使用jwt令牌的身份验证和授权。 IdentityServer4允许您指定权限（AS => Authentication Server），该权限用于处理对客户端（您的其他应用程序，.net，js或本机）进行身份验证。然后，将AS提供给客户端的令牌用于确定客户端是否有权访问API。您可以根据Claims指定哪些客户端可以访问哪些api，以及他们可以访问多少api。可以将Active Directory组转换为声明并按该级别进行授权。
优点：真正的好抽象，它们简化了过程的很大一部分。您可以保护任何类型的客户端（js / native / .net）。
缺点：您仍然必须学习OAuth2和OpenIdConnect规范，这可能需要花费一些时间。根据您尝试保护的应用程序网络的规模，您可能最终会编写大量配置。
JWT中间件
这仅允许api针对授权对令牌进行授权，并且它实际上没有提供“集中式身份验证结构”，您将不得不自行处理大量流程。通常只是IS4的精简版。
优点：一种将api保护到现有授权机构的快速简便的方法。
缺点：不允许您创建身份验证服务器。
摘要
如果您不打算保护本机应用程序或js应用程序的安全性，我会说Cookie共享。
如果您要设置基于令牌的身份验证，请阅读下文。
使用IdentityServer4获得长期灵活的解决方案，如果您有时间学习如何使用它并进行设置。
如果您有权限并且不介意使用JWT中间件进行一些设置，那么它将比Cookie共享更加灵活。