Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Conseil
Ce contenu est un extrait de l’eBook, Architecting Cloud Native .NET Applications pour Azure, disponible sur .NET Docs ou en tant que PDF téléchargeable gratuitement qui peut être lu hors connexion.
Télécharger le PDF
Duende IdentityServer est une infrastructure pour créer un serveur d’authentification conforme aux normes OpenID Connect (OIDC) et OAuth 2.x à l’aide de ASP.NET Core.
Il est conçu pour fournir un moyen courant d’authentifier les demandes auprès de toutes vos applications, qu’elles soient web, natives, mobiles ou API. IdentityServer peut être utilisé pour implémenter l’authentification unique (Sign-On SSO) pour plusieurs applications et types d’applications. Il peut être utilisé pour authentifier les utilisateurs réels via des formulaires de connexion et des interfaces utilisateur similaires, ainsi que l’authentification basée sur le service qui implique généralement l’émission, la vérification et le renouvellement de jetons sans interface utilisateur. Il peut également agir en tant que passerelle de fédération pour unifier les fournisseurs d’authentification.
IdentityServer est conçu pour être une solution personnalisable. Chaque instance est généralement personnalisée pour répondre à une organisation individuelle ou aux besoins d’un ensemble d’applications.
Scénarios courants d’application web
En règle générale, les applications doivent prendre en charge certains scénarios ou tous les scénarios suivants :
- Utilisateurs humains accédant aux applications web avec un navigateur.
- Utilisateurs humains accédant aux API web principales à partir d’applications basées sur un navigateur.
- Utilisateurs humains sur des clients mobiles/natifs accédant aux API web principales.
- D'autres applications accédant aux API web back-end (sans utilisateur actif ou interface utilisateur).
- Toute application peut avoir besoin d’interagir avec d’autres API web, en utilisant sa propre identité ou en déléguant l’identité de l’utilisateur.
Figure 8-1. Types et scénarios d’application.
Dans chacun de ces scénarios, les fonctionnalités exposées doivent être sécurisées contre une utilisation non autorisée. Au minimum, cela nécessite généralement l’authentification de l’utilisateur ou du principal à l’origine d’une demande de ressource. Cette authentification peut utiliser l’un des protocoles courants tels que SAML2p, WS-Fed ou OpenID Connect. La communication avec les API utilise généralement le protocole OAuth 2 et sa prise en charge des jetons de sécurité. La séparation de ces problèmes de sécurité critiques et de leurs détails d’implémentation des applications garantit la cohérence et améliore la sécurité et la maintenance. L’externalisation de ces préoccupations à un produit dédié comme IdentityServer permet à chaque application de résoudre ces problèmes lui-même.
IdentityServer fournit un intergiciel qui s’exécute dans une application ASP.NET Core et ajoute la prise en charge d’OpenID Connect et OAuth 2.x (voir spécifications prises en charge). À l’aide de IdentityServer, les organisations peuvent créer leur propre application ASP.NET Core à l’aide du middleware IdentityServer pour agir en tant que serveur d’autorisation pour tous leurs protocoles de sécurité basés sur des jetons. L’intergiciel IdentityServer expose les points de terminaison pour prendre en charge les fonctionnalités standard, notamment :
- Autoriser (authentifier l’utilisateur final)
- Jeton (demander un jeton par programmation)
- Découverte (métadonnées sur le serveur)
- Informations utilisateur (obtenir des informations utilisateur avec un jeton d’accès valide)
- Autorisation de l’appareil (utilisée pour démarrer l’autorisation du flux d’appareil)
- Introspection (validation de jetons)
- Révocation (révocation de jetons)
- Terminer la session (déclencher l’authentification unique sur toutes les applications)
- Demandes d’autorisation envoyées (pour un processus d’authentification plus sécurisé)
Commencer
IdentityServer est disponible :
- Avec une licence de communauté, qui vous permet d’utiliser la IdentityServer gratuitement pour les petites entreprises et les sans but lucratif (les conditions s’appliquent)
- La version payante, permettant d'utiliser l'IdentityServer dans un scénario commercial.
Pour plus d’informations sur la tarification, consultez la page de tarification du produit officiel.
Vous pouvez l’ajouter à vos applications à l’aide de ses packages NuGet. Le package principal est IdentityServer, qui a été téléchargé plus de quatre millions de fois. Le package de base n’inclut aucun code d’interface utilisateur et prend uniquement en charge la configuration en mémoire. Pour l’utiliser avec une base de données, vous souhaiterez également un fournisseur de données comme Duende.IdentityServer.Storage, qui utilise Entity Framework Core pour stocker la configuration et les données opérationnelles pour IdentityServer. Pour l’interface utilisateur, vous pouvez copier des fichiers à partir du référentiel d’exemples dans votre application Core MVC ASP.NET pour ajouter la prise en charge de la connexion et vous déconnecter à l’aide de l’intergiciel IdentityServer.
Paramétrage
IdentityServer prend en charge différents types de protocoles et de fournisseurs d’authentification sociale qui peuvent être configurés dans le cadre de chaque installation personnalisée. Cela est généralement effectué dans la classe de Program l’application ASP.NET Core. La configuration implique de spécifier les protocoles pris en charge et les chemins d’accès aux serveurs et points de terminaison qui seront utilisés. La figure 8-2 montre un exemple de configuration extrait du projet de démarrage rapide IdentityServer pour les applications ASP.NET Core :
// some details omitted
builder.Services.AddIdentityServer();
builder.Services.AddAuthentication(options =>
{
options.DefaultScheme = "Cookies";
options.DefaultChallengeScheme = "oidc";
})
.AddCookie("Cookies")
.AddGoogle("Google", options =>
{
options.SignInScheme = IdentityServerConstants.ExternalCookieAuthenticationScheme;
options.ClientId = "<insert here>";
options.ClientSecret = "<insert here>";
})
.AddOpenIdConnect("oidc", options =>
{
options.Authority = "https://localhost:5001";
options.ClientId = "web";
options.ClientSecret = "secret";
options.ResponseType = "code";
options.Scope.Clear();
options.Scope.Add("openid");
options.Scope.Add("profile");
options.MapInboundClaims = false; // Don't rename claim types
options.SaveTokens = true;
});
}
Figure 8-2. Configuration de IdentityServer.
Clients JavaScript
De nombreuses applications natives cloud utilisent des API côté serveur et des applications à page unique client enrichies sur le front-end, par exemple à l’aide de React, Angular ou Blazor WebAssembly. Le modèle backend-for-frontend (BFF) est utilisé pour ces types de clients, ce qui permet de conserver les jetons hors de portée du navigateur. Ce modèle suit la spécification OAuth 2.0 d’IETF pour Browser-Based Applications.
Références
Précédent Suivant