Identity Server

Présentation

IdentityServer est une librairie open source, développée par la société Duende, qui apporte le support du protocole OAuth 2.0 et sa surcouche OpenID Connect. Cette librairie vous permettra d’interagir avec les applications et les API qui auraient besoin d’obtenir ou de vérifier un token d’authentification, pas forcément un JWT d’ailleurs, en respectant les standards en vigueur.

IdentityServer est une librairie qui a vu le jour en 2009 sous le nom de StarterSTS. À l’époque, pas question de OAuth 2.0, le protocole est apparu en 2012, mais de WS-Federation, un ancien protocole qui n’est plus très utilisé de nos jours.

Puis sont apparus IdentityServer 1 et 2 qui ont apporté le support d’autres protocoles, dont OAuth 2.0, sortis depuis.

2014 a vu arriver IdentityServer 3 qui apportait le support d’OpenID Connect.

En 2016, c’est la version 4 qui a vu le jour. Avec elle est arrivé le support de .Net Core, mais également l’abandon des autres anciens protocoles pour ne conserver qu’OAuth2 et OpenID Connect qui étaient devenus les standards. La version 4 est la version qui a démocratisé IdentityServer et l’a vraiment rendu populaire, obtenant même un soutien de Microsoft qui en a fait la librairie standard pour l’authentification des projets Blazor. Le développement...

Installation

IdentityServer est distribué sous la forme d’un ensemble de Packages NuGet :

Pour la persistance des données, les interfaces fournies fonctionnent avec EntityFramework Core. Si vous souhaitez utiliser un autre ORM, il faudra réimplémenter vous-même les mécaniques de sauvegarde dans votre base de données.

Le package principal est Duende.IdentityServer, c’est celui-ci qu’il faudra installer en premier :

dotnet add package Duende.IdentityServer 

Comme nous utilisons ASP.Net Identity pour la gestion des utilisateurs, nous allons également ajouter le package Duende.IdentityServer.AspNetIdentity.

dotnet add package Duende.IdentityServer.AspNetIdentity 

Et comme nos données sont persistées au travers d’EntityFramework Core, nous allons ajouter le package nécessaire à la liaison entre les stores IdentityServer et EntityFramework Core :

dotnet add package Duende.IdentityServer.EntityFramework 

Pour consommer IdentityServer, il faudra ajouter les services nécessaires dans l’injection de dépendances :

builder.Services.AddIdentityServer(); 

La méthode AddIdentityServer() retourne un IIdentityServerBuilder et peut être configurée de deux manières : en y injectant une instance de IConfiguration contenant les bonnes propriétés, ou en réglant directement les options à disposition en paramètre de la méthode. Ces options étant extrêmement nombreuses et pointues, nous allons nous contenter des options de base pour le moment. Celles-ci font tout à fait l’affaire dans la majorité des cas.

Les données d’IdentityServer, que ce soit pour la configuration ou le fonctionnement, doivent être persistées dans des magasins. IdentityServer fournit les magasins et des implémentations de ceux-ci pour la persistance avec EntityFramework Core :

.AddConfigurationStore(o =>  
  o.ConfigureDbContext = ctx =>  
    ctx.UseSqlServer(connectionString,  
     ...

Les flux d’authentification

1. Authorization Code

Le flux d’authentification Authorization code est le plus répandu pour l’authentification d’un utilisateur humain. Il est également assez complexe avec de nombreux allers-retours entre le client et le serveur.

1. Le client appelle le endpoint Authorize pour recevoir l’autorisation de demander un token.

2. Si l’utilisateur n’est pas déjà authentifié, le SSO redirige celui-ci vers la page de connexion pour qu’il saisisse ses identifiants.

3. Les identifiants de l’utilisateur sont soumis au SSO qui va procéder à l’authentification. 

4. Si l’authentification est valide, le SSO retourne un code à durée de vie limitée (5 minutes par défaut).

5. L’utilisateur demande le token en fournissant le code qui lui a été transmis.

6. L’utilisateur reçoit son token, le flux est terminé.

Les stores

Les stores d’Identity Server sont des magasins de données qui contiennent les informations nécessaires au bon fonctionnement du SSO. Ces stores sont sauvegardés en bases de données grâce à l’interfaçage avec EntityFramework Core évoqué en début de chapitre.

Les ressources

Les ressources représentent des données ou des API auxquelles le porteur (Bearer) du token peut accéder. Pour accéder à une ou plusieurs ressources, le demandeur va demander un scope. Ce scope représente soit une IdentityResource s’il s’agit de données concernant l’utilisateur, soit un ApiScope ou une ApiResource si la ressource concerne une API.

public class IdentityResource : Resource  
{  
  public IdentityResource()  
  {  
  }  
  
  public IdentityResource(string name, IEnumerable<string> 
userClaims): this(name, name, userClaims)  
  {  
  }  
  public IdentityResource(string name, string displayName, 
IEnumerable<string> userClaims)  
  {  
    if (name.IsMissing()) throw new ArgumentNullException(nameof(name)); 
    if (userClaims.IsNullOrEmpty()) throw new ArgumentException("Must 
provide at least one claim type", nameof(userClaims));  
  
    Name = name;  
    DisplayName = displayName;  ...

Les clients

Un client est une application qui désire consommer l’authentification fournie par le SSO. Cette application peut être une application web classique, une application single page, une application desktop, mobile, un service autonome, etc.

Une application cliente est définie par la classe Client :

public class Client  
{  
    public bool Enabled { get; set; } = true;  
    public string ClientId { get; set; } = default!;  
    public string ProtocolType { get; set; } =  
IdentityServerConstants.ProtocolTypes.OpenIdConnect;  
    public ICollection<Secret> ClientSecrets { get; set; } = 
new HashSet<Secret>();  
    public bool RequireClientSecret { get; set; } = true;  
    public string? ClientName { get; set; }  
    public string? Description { get; set; }  
    public string? ClientUri { get; set; }  
    public string? LogoUri { get; set; }  
    public bool RequireConsent { get; set; } = false;  
    public bool AllowRememberConsent { get; set; } = true;  
    public ICollection<string> AllowedGrantTypes= new HashSet<string>(); 
    public bool RequirePkce { get; set; } = true;  
    public bool AllowPlainTextPkce { get; set; } = false;  
    public bool RequireRequestObject { get; set; } = false;  
    public bool AllowAccessTokensViaBrowser { get; set; } = false;  
    public ICollection<string> RedirectUris { get; set; } = 
new HashSet<string>(); 
    public ICollection<string> PostLogoutRedirectUris { get; set; } = 
new HashSet<string>();  
    public string? FrontChannelLogoutUri { get; set; }  
    public bool FrontChannelLogoutSessionRequired { get; set; } = true; 
    public string? BackChannelLogoutUri { get; set; }  
   ...

Les tokens

Les jetons, ou tokens, sont la base des systèmes OAuth et OpenId Connect. Comme nous l’avons abordé lors de la création de notre propre JWT, il s’agit d’une chaîne de caractère encodée en base 64 dont l’authenticité est assurée par un hash de signature. Toutefois, contrairement à notre implémentation maison, OAuth propose plusieurs types de tokens et ils ont des rôles bien particuliers que nous allons aborder ici.

Endpoints

Les endpoints sont les points de terminaison d’une API Web. Autrement dit, ce sont les points d’accès à une API Web, soit les routes que les utilisateurs vont appeler pour consommer votre API Web.

"issuer": https://localhost:7191 

"jwks_uri": 
https://localhost:7191/.well-known/openid-configuration/jwks 

"authorization_endpoint": 
https://localhost:7191/connect/authorize 

"token_endpoint": https://localhost:7191/connect/token 

"userinfo_endpoint": https://localhost:7191/connect/userinfo 

"end_session_endpoint": https://localhost:7191/connect/endsession 

"check_session_iframe": 
https://localhost:7191/connect/checksession 

"revocation_endpoint": https://localhost:7191/connect/revocation 

"introspection_endpoint": 
https://localhost:7191/connect/introspect 

"device_authorization_endpoint":...

Configuration d’IdentityServer

Nous avons vu les différentes parties qui composent IdentityServer. Tous ces éléments fonctionnent ensemble selon des règles préétablies que vous pouvez modifier grâce aux propriétés de configuration d’IdentityServer.

Lorsque vous ajoutez IdentityServer à votre conteneur de services via la commande :

builder.Services.AddIdentityServer(o =>  
{  
    ......  
}); 

Vous avez à disposition des dizaines de propriétés configurables. Les valeurs présentées sont les valeurs par défaut des propriétés :

  o.AccessTokenJwtType = "at+jwt"; 

Le type d’accès token retourné.

o.Authentication.CheckSessionCookieDomain = null; 

Domaine utilisé pour le cookie de session IdentityServer.

Si null, aucun domaine n’est renseigné dans le cookie.

o.Authentication.CheckSessionCookieName = "idsrv.session"; 

Nom utilisé pour le cookie de session IdentityServer.

o.Authentication.CheckSessionCookieSameSiteMode = 
SameSiteMode.None; 

Mode du cookie de session. Par défaut, la valeur est SameSiteMode.None, ce qui en fait un cookie "tiers" qui doit être obligatoirement crypté.

o.Authentication.CookieAuthenticationScheme = null; 

Scheme utilisé par le cookie d’authentification. Si rien n’est défini, c’est le scheme par défaut, de l’application, qui sera utilisé.

o.Authentication.CookieLifetime = TimeSpan.FromHours(10); 

Durée de vie du cookie d’authentification. Applicable uniquement si le cookie handler de IdentityServer est utilisé.

o.Authentication.CookieSameSiteMode = SameSiteMode.None; 

Mode du cookie d’authentification.

o.Authentication.CookieSlidingExpiration = false; 

Durée de vie glissante du cookie d’authentification. Par défaut, la date d’expiration du cookie est fixe.

o.Authentication.CoordinateClientLifetimesWithUserSession = false; 

Synchronise la durée de vie des tokens avec les sessions utilisateur. Si activé, ce paramètre purge tous les refresh tokens d’un utilisateur quand celui-ci se déconnecte. Ce qui le déconnecte...

Amorçage de la base de données

Identity server se sert d’une base de données pour persister toutes les informations de configuration vues dans ce chapitre. Afin de faciliter les choses, Identity Server fournit les implémentations nécessaires pour fonctionner avec Entity Framework Core. Les données sont ensuite enregistrées dans la base de données que vous avez choisie, Entity Framework Core faisant l’abstraction de cette base.

public static class Seed 
{ 
  public static Task SeedDatabase(this WebApplication app) 
  { 
    return Task.CompletedTask; 
  } 
} 

WebApplication app = builder.Build(); 
await app.SeedDatabase(); 
...... 
App.Run(); 

IServiceScope scope = app.Services.CreateScope(); 

ApplicationDbContext applicationDbContext = 
scope.ServiceProvider.GetRequiredService<ApplicationDbContext>(); 
await applicationDbContext.Database.MigrateAsync(); 
 
ConfigurationDbContext configurationDbContext = 
scope.ServiceProvider.GetRequiredService<ConfigurationDbContext>(); 
await configurationDbContext.Database.MigrateAsync(); 
PersistedGrantDbContext persistedGrantDbContext = 
scope.ServiceProvider.GetRequiredService<PersistedGrantDbContext>(); 
await persistedGrantDbContext.Database.MigrateAsync();