Skip to main content
Dans cette section, nous passerons en revue la solution que nous mettons en œuvre, y compris la gestion des identités, les protocoles à utiliser et le flux d’authentification requis.

​
Gestion des identités

ExampleCo a décidé d’utiliser Auth0 comme fournisseur d’Identity as a Service (IDaaS). Cette décision s’explique par le fait que l’entreprise ne voulait pas consacrer de ressources à la formation, à la mise en œuvre et à la maintenance de la gestion des identités et des accès. De plus, l’entreprise prévoit faire évoluer cette solution à l’avenir, en y ajoutant possiblement une application mobile native et une API pour transmettre les feuilles de temps approuvées à ses systèmes internes. Auth0 offre la souplesse nécessaire pour intégrer de tels changements à son architecture avec un minimum d’efforts.
L’Identity as a Service (« IDaaS ») est un service infonuagique de gestion des identités et des accès. Les services offerts comprennent souvent l’authentification unique (SSO), l’identité fédérée, la gestion des mots de passe, et plus encore.

​
Quel protocole utiliser

La prochaine décision consiste à choisir le protocole à utiliser, avec  Connect (OIDC) ou .
Auth0 implémente des protocoles d’identité éprouvés, courants et largement utilisés, autant pour les produits Web destinés aux consommateurs (OAuth 2.0, OAuth 1.0, OpenID) que pour les déploiements en entreprise (SAML, WS-Federation, LDAP). Vous êtes entièrement libre d’utiliser celui qui répond le mieux à vos besoins d’affaires.
OpenID Connect est un protocole d’authentification fondé sur la famille de spécifications OAuth 2.0. Il utilise de simples JSON () transmis au moyen du protocole OAuth 2.0.

​
OAuth vs OpenID Connect (OIDC)

OAuth 2.0 et OpenID Connect (OIDC) sont souvent confondus, mais ce n’est pas tout à fait exact. OAuth 2.0 est un protocole qui vous permet d’autoriser un site Web (le consommateur ou l’application) à accéder à vos données sur un autre site Web (le serveur de ressources ou fournisseur). Par exemple, vous voulez autoriser un site Web à accéder à certains fichiers de votre compte Dropbox. Le site Web vous redirige vers Dropbox, qui vous demande s’il doit autoriser l’accès à vos fichiers. Si vous acceptez, le site Web sera autorisé à accéder à vos fichiers dans Dropbox. Au fond, OAuth 2.0 concerne l’accès aux ressources et leur partage. OpenID Connect, quant à lui, est une simple couche d’identité construite sur le protocole OAuth 2.0. Il vous permet d’avoir une seule connexion pour plusieurs sites. Chaque fois que vous devez vous connecter à un site Web à l’aide d’OIDC, vous êtes redirigé vers votre site OpenID, où vous vous connectez, puis renvoyé vers le site Web. Au fond, OIDC concerne l’authentification des utilisateurs.
SAML est un protocole fondé sur XML qui assure à la fois l’authentification et l’autorisation entre des parties de confiance. Comparativement à SAML, OpenID Connect est plus léger et plus simple à utiliser. SAML est éprouvé, puissant et flexible, mais pour les besoins de cette application, cette flexibilité et cette puissance ne sont pas nécessaires. La fédération d’identité (l’une des raisons les plus convaincantes d’adopter SAML) n’est pas non plus requise ici. Et si cela devait un jour devenir nécessaire, Auth0 pourrait facilement le prendre en charge, de la même manière qu’il gère AD (qui utilise LDAP). Pour ces raisons, ExampleCo utilisera OpenID Connect pour sa mise en œuvre.

​
Flux d’authentification

OpenID Connect prend en charge plus d’un flux d’authentification. Comme notre scénario met en jeu une application web traditionnelle, nous utiliserons le flux de code d’autorisation. Le flux se déroule comme suit :
  1. L’application web (appelée client dans la terminologie OIDC) lance la requête d’authentification en redirigeant l’agent utilisateur (navigateur) vers Auth0 (le serveur d’autorisation dans la terminologie OIDC).
  2. Auth0 authentifie l’utilisateur (par l’intermédiaire de l’agent utilisateur). La première fois que l’utilisateur passe par ce flux, une page de consentement s’affiche, où sont indiquées les permissions qui seront accordées à l’application (par exemple, publier des messages, répertorier des contacts). L’utilisateur se connecte au service (s’il n’est pas déjà connecté) et autorise l’accès à l’application.
  3. Si l’utilisateur accorde l’accès, Auth0 redirige l’agent utilisateur vers l’application avec un code d’autorisation dans la chaîne de requête.
  4. L’application envoie le code d’autorisation à Auth0, avec les identifiants de l’application (client_id et client_secret), et demande un jeton.
  5. Auth0 authentifie l’application (à l’aide de client_id et client_secret) et valide le code d’autorisation. S’il est valide, Auth0 renvoie un ID Token.
undefined

​
Mode de réponse Form Post

Une autre option consiste à utiliser le mode de réponse Form Post OAuth 2.0 avec response_type=id_token&response_mode=form_post. En raison du paramètre de requête response_type=id_token, la réponse contient directement l’ID Token, au lieu du code d’autorisation, tandis que response_mode=form_post encode l’ID Token avec le reste des paramètres de la réponse d’autorisation sous forme de valeurs de formulaire HTML soumises automatiquement dans l’agent utilisateur. Vous obtenez ainsi un flux d’authentification optimisé (inutile d’échanger le code contre un ID Token), mais vous devez vous assurer que la technologie utilisée pour implémenter votre application le prend en charge (c’est le cas du middleware ASP .NET Core). Pour en savoir plus, consultez la spécification OAuth 2.0 Form Post Response Mode.
Le ID Token (généralement appelé id_token dans les exemples de code) est un JSON Web Token (JWT) qui contient des données d’identité. Il est utilisé par l’application pour obtenir des renseignements sur l’utilisateur, comme son nom, son courriel, etc., généralement à des fins d’affichage dans l’interface utilisateur.

​
En savoir plus sur les jetons

Les jetons sont des chaînes alphanumériques utilisées dans l’authentification fondée sur les jetons. Ils permettent aux utilisateurs de s’authentifier une seule fois avec un nom d’utilisateur et mot de passe, puis d’obtenir un jeton en retour qu’ils peuvent utiliser par la suite. Leur durée de vie est limitée.Les JSON Web Tokens (JWTs) sont des jetons conformes à la norme JSON Web Token et contiennent des renseignements sur une identité sous forme de claims. Ils sont autonomes, en ce sens que le destinataire n’a pas besoin d’appeler un serveur pour valider le jeton. Les JWTs peuvent être signés au moyen d’un secret (avec l’algorithme HMAC) ou d’une paire de clés publique/privée au moyen de RSA. Vous trouverez plus d’information sur les JWT ici.L’ID Token, qui est un JWT, est conforme à une norme de l’industrie (IETF RFC 7519) et contient trois parties : un en-tête, un corps et une signature.
  • L’en-tête contient le type de jeton et l’algorithme de hachage utilisé sur le contenu du jeton.
  • Le corps, aussi appelé le payload, contient des claims d’identité sur un utilisateur. Il existe certains claims portant des noms enregistrés, pour des éléments comme l’émetteur du jeton, le sujet du jeton (la personne à laquelle les claims se rapportent) et l’heure d’émission. Il est possible d’ajouter n’importe quel nombre de claims supplémentaires portant d’autres noms, mais il faut veiller à ce que le JWT respecte les limites de taille des URL dans le navigateur.
  • La signature est utilisée par le destinataire d’un JWT pour valider l’intégrité de l’information transmise dans le JWT.

​
Comment valider un ID Token

La validation d’un ID Token exige plusieurs étapes :
  1. Si l’ID Token est chiffré, déchiffrez-le à l’aide des clés et des algorithmes qu’a spécifiés l’Application.
  2. L’identifiant de l’émetteur du fournisseur OpenID doit correspondre à la valeur du claim iss (issuer).
  3. Le claim aud (audience) doit contenir la valeur client_id de l’Application. L’ID Token doit être rejeté s’il n’indique pas l’Application comme audience valide, ou s’il contient des audiences supplémentaires auxquelles l’Application ne fait pas confiance.
  4. Si l’ID Token contient plusieurs audiences, l’Application doit vérifier qu’un claim azp est présent.
  5. Si un claim azp (authorized party) est présent, l’Application doit vérifier que son client_id correspond à la valeur du claim.
  6. L’Application doit valider la signature des ID Tokens conformément à JWS en utilisant l’algorithme indiqué dans le paramètre d’en-tête JWT alg. L’Application doit utiliser les clés fournies par l’émetteur.
  7. La valeur alg doit être la valeur par défaut RS256 ou l’algorithme envoyé par l’Application dans le paramètre id_token_signed_response_alg pendant l’enregistrement.
  8. Si le paramètre d’en-tête JWT alg utilise un algorithme fondé sur un MAC comme HS256, HS384 ou HS512, les octets de la représentation UTF-8 du client_secret correspondant au client_id contenu dans le claim aud (audience) sont utilisés comme clé pour valider la signature. Pour les algorithmes fondés sur un MAC, le comportement n’est pas précisé si aud contient plusieurs valeurs ou si une valeur azp est présente et diffère de la valeur aud.
  9. L’heure actuelle doit être antérieure à l’heure indiquée par le claim exp.
  10. Le claim iat peut être utilisé pour rejeter les jetons qui ont été émis trop loin dans le temps par rapport à l’heure actuelle, ce qui limite la durée pendant laquelle les nonce doivent être stockés afin de prévenir les attaques. La plage acceptable dépend de l’Application.
  11. Si une valeur nonce a été envoyée dans la requête d’authentification, un claim nonce doit être présent et sa valeur doit être vérifiée afin de confirmer qu’il s’agit de la même valeur que celle qui a été envoyée dans la requête d’authentification. L’Application doit vérifier la valeur nonce pour prévenir les replay attacks. La méthode précise pour détecter les replay attacks dépend de l’Application.
  12. Si le claim acr a été demandé, l’Application doit vérifier que la valeur du claim est appropriée.
  13. Si le claim auth_time a été demandé, soit par une demande précise de ce claim, soit à l’aide du paramètre max_age, l’Application doit vérifier la valeur du claim auth_time et demander une nouvelle authentification si elle détermine que trop de temps s’est écoulé depuis la dernière authentification de l’utilisateur final.
Si vous stockez des ID Tokens sur votre serveur, vous devez le faire de manière sécuritaire.