Blog ENI : Toute la veille numérique !
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
💥 Les 22 & 23 novembre : Accès 100% GRATUIT
à la Bibliothèque Numérique ENI. Je m'inscris !
  1. Livres et vidéos
  2. OAuth 2 et OpenID Connect
  3. Les fournisseurs externes d'authentification
Extrait - OAuth 2 et OpenID Connect Sécurisez vos applications .Net avec IdentityServer
Extraits du livre
OAuth 2 et OpenID Connect Sécurisez vos applications .Net avec IdentityServer Revenir à la page d'achat du livre

Les fournisseurs externes d'authentification

Qu’est-ce qu’un fournisseur externe d’authentification ?

Ce que l’on nomme fournisseur externe d’authentification est une application, de type SSO le plus souvent, à qui on va déléguer la charge de vérifier l’identité d’un utilisateur.

Un exemple très connu et courant est Facebook. Sur de nombreux sites, vous pouvez vous connecter et créer un compte en utilisant votre compte Facebook.

Dans ce cas, on va déléguer à Facebook la responsabilité de vérifier que vous êtes bien qui vous prétendez. Si tel est le cas, Facebook nous répondra en disant « j’ai bien authentifié l’utilisateur suivant : ... » Les informations vous concernant dans ce cas sont, a minima, un identifiant. Celui-ci permettra de faire la jonction entre l’identifiant Facebook et votre identifiant local. Dans la pratique, l’e-mail est quasi toujours transmis comme propriété de base, car c’est ça qui permettra de créer le compte utilisateur local. Il peut y avoir également votre prénom et votre nom. Dans tous les cas, les applications indiquent explicitement les informations demandées pour que l’utilisateur donne son consentement.

Certains systèmes, comme celui d’Apple, permettent de masquer votre e-mail aux fournisseurs externes...

Les fournisseurs « built-in »

Par défaut, ASP.Net fournit des connecteurs pour quatre fournisseurs externes : Facebook, Twitter, Google et, bien sûr, Microsoft.

Pour les utiliser, il suffit d’installer les packages NuGet correspondants :

images/07EI001.png

Installons le fournisseur de connexion à Facebook. Pour l’utiliser, il faudra ajouter l’authentification et le service Facebook dans votre injection de dépendances.

Fichier Program.cs :

builder.Services.AddAuthentication()  
  .AddFacebook(); 

La méthode AddAuthentication() ajoute l’authentification et retourne un AuthenticationBuilder. C’est sur cette classe AuthenticationBuilder que vient se brancher la méthode d’extension AddFacebook();.

Sans préciser d’arguments, la méthode ajoute l’authentification Facebook avec les paramètres par défaut. Ces paramètres par défaut sont contenus dans la classe FacebookDefaults :

public static class FacebookDefaults  
{  
    public const string AuthenticationScheme = "Facebook";  
   
    public static readonly string DisplayName = "Facebook";  
   
    public static readonly string AuthorizationEndpoin  = 
"https://www.facebook.com/v11.0/dialog/oauth";  
  
    public static readonly string TokenEndpoint = 
"https://graph.facebook.com/v11.0/oauth/access_token";  
  
    public static readonly string UserInformationEndpoint = 
"https://graph.facebook.com/v11.0/me";  
} 

On y retrouve les informations de base, dans l’ordre :

  • le scheme ;

  • le nom du provider ;

  • l’url d’authentification ;

  • l’URL de requête de token ;

  • l’URL des informations utilisateur.

La notion de scheme est importante. Chaque mode d’authentification a son propre scheme, c’est son identifiant. Pour Facebook, ce sera Facebook ; pour Google, ce sera Google ; pour un token JWT (Json Web Token), ce sera Bearer, etc. Le scheme va permettre de savoir par quelle méthode vous souhaitez vous authentifier.

Facebook utilise le protocole d’autorisation OAuth2. Celui-ci nécessite...

Les packages NuGet AspNet.Security.OAuth.Providers

En dehors des quatre fournisseurs de base fournis par ASP.Net, il existe une multitude de packages pour des fournisseurs connus tels que Apple, LinkedIn, GitHub, Instagram, etc.

Cette collection de fournisseurs est maintenue par la communauté et les sources sont disponibles sur GitHub.

Vous pouvez retrouver la liste complète ici :  https://github.com/aspnet-contrib/AspNet.Security.OAuth.Providers

Chaque provider fournissant une méthode d’extension pour l’injection du service comparable à celle que nous venons de voir avec Facebook.

Fournisseurs personnalisés

Dans le cas où vous ne trouveriez pas votre bonheur dans la liste des fournisseurs prêts à l’emploi, il vous reste la possibilité de configurer un fournisseur personnalisé. Imaginez qu’un client désire s’authentifier à votre système en utilisant son propre système d’authentification. Dans ce cas, l’ajout de son système d’authentification va se faire comme nous avons ajouté Facebook. La différence étant que la méthode d’extension qui gère la connexion à Facebook masque une bonne partie de la complexité de OAuth2.

La classe FacebookOptions qui hérite de la classe OAuthOptions préconfigure la majeure partie des options afin que vous n’ayez qu’à renseigner le ClientId et ClientSecret qui sont les deux éléments variables d’un client à l’autre.

public FacebookOptions()  
{  
  CallbackPath = new PathString("/signin-facebook");  
  SendAppSecretProof = true;  
  AuthorizationEndpoint = FacebookDefaults.AuthorizationEndpoint; 
  TokenEndpoint = FacebookDefaults.TokenEndpoint;  
  UserInformationEndpoint = FacebookDefaults.UserInformationEndpoint; 
  Scope.Add("email");  
  Fields.Add("name");  
  Fields.Add("email");  
  Fields.Add("first_name");  
  Fields.Add("last_name");  
  
  ClaimActions.MapJsonKey(ClaimTypes.NameIdentifier, "id");  
  ClaimActions.MapJsonSubKey("urn:facebook:age_range_min", 
"age_range", "min");  
  ClaimActions.MapJsonSubKey("urn:facebook:age_range_max", 
"age_range", "max"); 
  ClaimActions.MapJsonKey(ClaimTypes.DateOfBirth, "birthday");  
  ClaimActions.MapJsonKey(ClaimTypes.Email, "email");  
  ClaimActions.MapJsonKey(ClaimTypes.Name, "name");  
  ClaimActions.MapJsonKey(ClaimTypes.GivenName, "first_name");  
  ClaimActions.MapJsonKey("urn:facebook:middle_name"...

Conclusion

Nous avons maintenant une application d’authentification qui nous permet de nous identifier de manière classique via un e-mail et un mot de passe, ou en ayant recours à un fournisseur tiers comme Facebook, Twitter, Google ou Microsoft ou tout autre fournisseur s’appuyant sur le protocole OAuth2. Pourtant, nous n’avons pas encore un SSO. En effet, notre système « se contente » de nous authentifier pour lui-même. Ceci est très bien si le système d’authentification fait partie intégrante d’une application web unique comme un site de vente en ligne. Une application externe voulant consommer notre authentification ne pourra le faire car elle ne pourra pas consommer notre cookie d’authentification. La prochaine étape sera donc de fournir à des applications externes quelque chose qui permet de justifier de l’authentification de notre utilisateur. Ce quelque chose est un Json Web Token.