IdentityServer4与AspNet.Security.OpenIdConnect.Server与OpenIddict的比较

Question

IdentityServer4与AspNet.Security.OpenIdConnect.Server与OpenIddict的比较

asp.net-coreopenid-connectidentityserver4openiddict

35

为了了解我可以用什么来实现OpenId Connect服务器，我研究了每个选项：

IdentityServer4:

一个ASP.NET Core 2的OpenID Connect和OAuth 2.0框架。
AspNet.Security.OpenIdConnect.Server:

是一个高级的OAuth2/OpenID Connect服务器框架，适用于ASP.NET Core 1.x/2.x和OWIN/Katana 3.x/4.x，旨在提供低级别、协议优先的方法。
OpenIddict:

OpenIddict旨在为任何ASP.NET Core 1.x或2.x应用程序中实现OpenID Connect服务器提供简单易用的解决方案。

OpenIddict基于AspNet.Security.OpenIdConnect.Server来控制OpenID Connect认证流程，并可与任何成员资格堆栈一起使用，包括ASP.NET Core Identity。
同时我也检查了它们都很好地使用ASP.NET Core Identity作为成员资格系统。

我的理解是，IdentityServer4和OpenIdConnect.Server是两个解决同一问题的可替代框架。主要区别在于支持的ASP.NET Core版本列表。

关于Openiddict - 它是一种扩展，旨在简化基于AspNet.Security.OpenIdConnect.Server的服务器创建。

我有遗漏什么吗？还是这通常就是情况？

- Set

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Kévin Chalet · Accepted Answer

编辑 (2021年1月28日):在3.0更新的一部分中，AspNet.Security.OpenIdConnect.Server和OpenIddict合并为一个单一/统一的代码库，在OpenIddict的保护下提供了最佳选择：您仍然拥有以前相同的体验，但现在可以选择降级模式，给高级用户提供与AspNet.Security.OpenIdConnect.Server相同的底层方法。

因此，我目前的理解是IdentityServer4和OpenIdConnect.Server是解决同样问题的两个替代框架。其中主要的区别是支持的ASP.NET Core版本列表。

实际上，我认为最重要的区别是这两个库没有共享相同的目标。ASOS的唯一使命是帮助您处理原始的OAuth 2.0 / OIDC协议详细信息：其他所有内容都完全超出范围。具体来说，这意味着在ASOS中找不到像OpenIddict和IdentityServer中的用户、应用程序或存储之类的概念（这意味着您可以自由地引入自己的实现...和自己的抽象）。

而IdentityServer将公开许多抽象和服务，允许配置特定功能，ASOS - 它从卡塔纳的OAuthAuthorizationServerMiddleware分叉而来 - 具有集中的低级事件型API（称为OpenIdConnectServerProvider），其行为与MSFT开发的ASP.NET Core安全中间件完全相同。

在使用ASOS时，您需要处理原始的OpenID Connect请求，并实现可能涉及敏感信息的事情，例如客户端身份验证（例如使用包含客户端凭据的数据库），因此ASOS的核心目标是了解OAuth2/OIDC协议工作方式的人。而另一方面，OpenIddict和IdentityServer将为您实现这些内容。

关于Openiddict-它是一种扩展，可简化基于AspNet.Security.OpenIdConnect.Server创建服务器的过程。

最初，这确实是我被要求设计的方式。OpenIddict是为那些不熟悉OAuth 2.0和OpenID Connect协议详细信息的非专家创建的。

虽然它可以让您完全灵活地实现用户身份验证部分（例如在自己的授权控制器中使用ASP.NET Core Identity或自己的身份验证方法），但它会处理复杂的请求验证过程，并使其对您的应用程序透明，而不会淹没您的大量配置选项。

与ASOS不同（它试图尽可能灵活，并尽可能接近规范），OpenIddict通常具有更严格的验证例程，我个人认为这是最佳做法。例如，如果客户端是保密应用程序，则它将自动拒绝包含response_type=token的授权请求，即使这不被OpenID Connect规范禁止。