IdentityServer4 vs AspNet.Security.OpenIdConnect.Server vs OpenIddict
Afin de comprendre ce que je peux utiliser pour la mise en œuvre d'OpenId Connect Server, j'ai examiné ce que chacun d'eux est:
une connexion OpenID et une infrastructure OAuth 2.0 pour ASP.NET Core 2.
AspNet.Security.OpenIdConnect.Server :
est une infrastructure de serveur OAuth2/OpenID Connect avancée pour ASP.NET Core 1.x/2.x et OWIN/Katana 3.x/4.x, conçue pour offrir une approche de bas niveau basée sur le protocole.
OpenIddict vise à fournir une solution simple et facile à utiliser pour implémenter un serveur OpenID Connect dans n'importe quelle application ASP.NET Core 1.x ou 2.x.
OpenIddict est basé sur
AspNet.Security.OpenIdConnect.Serverpour contrôler le flux d'authentification OpenID Connect et peut être utilisé avec n'importe quelle pile d'appartenance, y compris ASP.NET Core Identity.Ont également vérifié que tous utilisent bien ASP.NET Core Identity comme système d'adhésion.
Et donc ma compréhension actuelle est que IdentityServer4 et OpenIdConnect.Server sont deux cadres alternatifs qui résolvent le même problème. La principale différence est la liste des versions d'ASP.NET Core prises en charge.
Concernant Openiddict - c'est une sorte d'extension pour simplifier la création de serveur basée sur AspNet.Security.OpenIdConnect.Server.
Ai-je raté quelque chose, ou c'est comme ça que ça se passe en général?
Et donc ma compréhension actuelle est que IdentityServer4 et OpenIdConnect.Server sont deux cadres alternatifs qui résolvent le même problème. La principale différence est la liste des versions d'ASP.NET Core prises en charge.
En fait, je crois que la différence la plus importante est que ces deux bibliothèques ne partagent pas le même objectif. La seule mission d'ASOS est de vous aider à gérer les détails bruts du protocole OAuth2/OIDC: tout le reste est totalement hors de portée. Concrètement, cela signifie que des concepts tels que les utilisateurs, les applications ou les magasins - que vous pouvez trouver dans OpenIddict et IdentityServer - sont totalement inexistants dans ASOS (ce qui signifie que vous êtes libre d'apporter votre propre implémentation ... et votre propre abstraction).
Alors qu'IdentityServer exposera de nombreuses abstractions et services permettant de configurer des fonctionnalités spécifiques, ASOS - issu de OAuthAuthorizationServerMiddleware de Katana - dispose d'une API basée sur les événements de bas niveau centralisée (nommée OpenIdConnectServerProvider) qui se comporte exactement de la même manière que le middleware de sécurité ASP.NET Core développé par MSFT.
Lorsque vous travaillez avec ASOS, vous devez traiter les demandes OpenID Connect brutes et implémenter des éléments potentiellement sensibles comme l'authentification client (par exemple en utilisant une base de données contenant les informations d'identification du client) et c'est pourquoi la cible principale d'ASOS est les personnes qui comprennent le fonctionnement du protocole OAuth2/OIDC . OpenIddict et IdentityServer, d'autre part, implémenteront ces choses pour vous.
Concernant Openiddict - c'est une sorte d'extension pour simplifier la création de serveur basée sur AspNet.Security.OpenIdConnect.Server.
Au départ, c'est bien ainsi qu'on m'a demandé de le concevoir. OpenIddict a été créé pour les non-experts qui ne se sentent pas très à l'aise avec les détails du protocole d'OAuth2 et d'OpenID Connect.
Bien qu'il vous donnera une flexibilité totale pour implémenter la partie d'authentification des utilisateurs (par exemple dans votre propre contrôleur d'autorisation, en utilisant ASP.NET Core Identity ou votre propre méthode d'authentification), il gérera le processus de validation des demandes complexes et le rendra transparent pour votre application, sans vous noyer avec des tonnes d'options de configuration.
Contrairement à ASOS (qui essaie d'être aussi flexible et aussi proche des spécifications que possible), OpenIddict est généralement livré avec des routines de validation plus restrictives que je considère personnellement comme les meilleures pratiques. Par exemple, il rejettera automatiquement les demandes d'autorisation contenant response_type=token si le client est une application confidentielle, même si cela n'est pas interdit par la spécification OpenID Connect.