IdentityServer pour les applications natives cloud
Conseil
Ce contenu est un extrait du livre électronique, Cloud Native .NET apps for Azure (Architecture d’applications .NET natives cloud pour Azure), disponible dans la documentation .NET ou au format PDF à télécharger gratuitement pour le lire hors connexion.
IdentityServer est un serveur d’authentification qui implémente les normes OpenID Connect (OIDC) et OAuth 2.0 pour ASP.NET Core. Il est conçu pour fournir un moyen courant d’authentifier les demandes à toutes vos applications, qu’elles soient web, natives, mobiles ou des points de terminaison d’API. IdentityServer peut être utilisé pour implémenter l’authentification unique (SSO) dans plusieurs applications et types d’applications. Il peut être utilisé pour authentifier les utilisateurs via des formulaires de connexion et interfaces utilisateur similaires, ainsi qu’une authentification basée sur un service qui implique généralement l’émission, la vérification et le renouvellement de jetons sans interface utilisateur. IdentityServer est conçu pour être une solution personnalisable. Chaque instance est généralement personnalisée pour répondre aux besoins d’une organisation et/ou d’un ensemble d’applications.
Scénarios courants pour les applications web
En règle générale, les applications doivent prendre en charge une partie ou l’ensemble des scénarios suivants :
- Utilisateurs humains accédant aux applications web avec un navigateur.
- Utilisateurs humains accédant aux API web back-end à partir d’applications basées sur un navigateur.
- Utilisateurs humains sur des clients mobiles/natifs accédant aux API web back-end.
- Autres applications accédant aux API web back-end (sans utilisateur actif ni 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 d’applications et scénarios.
Dans chacun de ces scénarios, la fonctionnalité exposée doit être sécurisée contre toute utilisation non autorisée. Au minimum, cela demande 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 différents protocoles courants tels que SAML2p, WS-FED ou OpenID Connect. La communication avec les API utilise généralement le protocole OAuth2 et sa prise en charge des jetons de sécurité. Le fait de séparer ces préoccupations de sécurité transversales critiques et leurs détails d’implémentation des applications elles-mêmes garantit une cohérence et améliore la sécurité et la maintenabilité. L’externalisation de ces préoccupations à un produit dédié comme IdentityServer permet à chaque application de résoudre ces problèmes elle-même.
IdentityServer fournit un middleware qui s’exécute dans une application ASP.NET Core et qui assure la prise en charge d’OpenID Connect et d’OAuth2 (voir les spécifications prises en charge). Les organisations pourraient ainsi créer leur propre application ASP.NET Core en utilisant le middleware IdentityServer comme STS pour tous leurs protocoles de sécurité basés sur des jetons. Le middleware IdentityServer expose des points de terminaison pour prendre en charge les fonctionnalités standard, notamment :
- Autorisation (authentifier l’utilisateur final)
- Jeton (demander un jeton programmatiquement)
- Découverte (métadonnées sur le serveur)
- Informations utilisateur (obtenir les 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)
- Mettre fin à la session (déclencher une déconnexion unique sur toutes les applications)
Prise en main
IdentityServer4 est disponible sous une licence double :
- RPL - vous permet d’utiliser IdentityServer4 gratuitement s’il est utilisé dans le cadre d’un travail open source
- Payant - vous permet d’utiliser IdentityServer4 dans un scénario commercial
Pour plus d’informations sur les prix, consultez la page des tarifs du produit officiel.
Vous pouvez l’ajouter à vos applications à l’aide de ses packages NuGet. Le package principal est IdentityServer4, 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 une configuration en mémoire. Pour l’utiliser avec une base de données, vous souhaiterez également un fournisseur de données comme IdentityServer4.EntityFramework, qui utilise Entity Framework Core pour stocker la configuration et les données opérationnelles pour IdentityServer. Pour l’interface utilisateur, vous pouvez copier les fichiers du dépôt Quickstart UI dans votre application ASP.NET Core MVC pour ajouter la prise en charge des connexions et déconnexions avec le middleware IdentityServer.
Configuration
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. Cette opération est généralement effectuée dans la classe Program de l’application ASP.NET Core (ou dans la classe Startup de la méthode ConfigureServices). La configuration implique la spécification des protocoles pris en charge et des chemins des serveurs et points de terminaison qui seront utilisés. La figure 8-2 montre un exemple de configuration extrait du projet Quickstart UI IdentityServer4 :
public class Startup
{
public void ConfigureServices(IServiceCollection services)
{
services.AddMvc();
// some details omitted
services.AddIdentityServer();
services.AddAuthentication()
.AddGoogle("Google", options =>
{
options.SignInScheme = IdentityServerConstants.ExternalCookieAuthenticationScheme;
options.ClientId = "<insert here>";
options.ClientSecret = "<insert here>";
})
.AddOpenIdConnect("demoidsrv", "IdentityServer", options =>
{
options.SignInScheme = IdentityServerConstants.ExternalCookieAuthenticationScheme;
options.SignOutScheme = IdentityServerConstants.SignoutScheme;
options.Authority = "https://demo.identityserver.io/";
options.ClientId = "implicit";
options.ResponseType = "id_token";
options.SaveTokens = true;
options.CallbackPath = new PathString("/signin-idsrv");
options.SignedOutCallbackPath = new PathString("/signout-callback-idsrv");
options.RemoteSignOutPath = new PathString("/signout-idsrv");
options.TokenValidationParameters = new TokenValidationParameters
{
NameClaimType = "name",
RoleClaimType = "role"
};
});
}
}
Figure 8-2 : Configuration d’IdentityServer.
Clients JavaScript
De nombreuses applications natives cloud utilisent des API côté serveur et des applications monopages (SPA) clientes riches sur le front-end. IdentityServer fournit un client JavaScript (oidc-client.js) via NPM qui peut être ajouté aux applications monopages pour leur permettre d’utiliser IdentityServer pour la connexion, la déconnexion et l’authentification basée sur les jetons des API web.
