Passer au contenu principal
Dans cette section, nous présenterons la solution mise en œuvre, notamment des détails sur 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, notamment en y ajoutant une application mobile native et une API pour acheminer les feuilles de temps approuvées vers ses systèmes internes. Auth0 offre la flexibilité nécessaire pour intégrer ce type de changements à cette architecture avec un minimum d’effort.
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 décision suivante consiste à déterminer quel protocole utiliser, avec  Connect (OIDC) ou .
Auth0 met en œuvre des protocoles d’identité éprouvés, courants et populaires, tant 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 à partir d’un autre site Web (le serveur de ressources ou le fournisseur). Par exemple, vous souhaitez autoriser un site Web à accéder à certains fichiers de votre compte Dropbox. Le site Web vous redirigera vers Dropbox, qui vous demandera s’il doit autoriser l’accès à vos fichiers. Si vous acceptez, le site Web sera autorisé à accéder à vos fichiers depuis Dropbox. Essentiellement, OAuth 2.0 porte sur l’accès aux ressources et leur partage. OpenID Connect, quant à lui, est une simple couche d’identité construite au-dessus du protocole OAuth 2.0. Il vous offre 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 vous êtes renvoyé vers le site Web. Essentiellement, OIDC concerne l’authentification de l’utilisateur.
SAML est un protocole fondé sur XML qui fournit à 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 exigences 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 elle le devenait un jour, Auth0 pourrait facilement la prendre en charge, de la même façon qu’il gère AD (qui utilise LDAP). Pour ces raisons, ExampleCo utilisera OpenID Connect pour son implémentation.

​
Flux d’authentification

OpenID Connect prend en charge plusieurs flux d’authentification. Comme notre scénario concerne 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 le Client dans la terminologie OIDC) lance la demande d’authentification en redirigeant l’agent utilisateur (le 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 autorisations qui seront accordées à l’application (par exemple, publier des messages, afficher la liste des contacts). L’utilisateur ouvre une session dans le service (à moins qu’il ne soit déjà connecté) et autorise l’application à y accéder.
  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 ses identifiants (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 OAuth 2.0 Form Post avec response_type=id_token&response_mode=form_post. Comme le paramètre de requête response_type=id_token est utilisé, la réponse contient directement l’ID Token plutôt que le 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é (il n’est pas nécessaire d’échanger le code contre un ID Token). Vous devez toutefois 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 des jetons. Ils permettent aux utilisateurs de s’authentifier une seule fois avec un nom d’utilisateur et un mot de passe, puis de recevoir un jeton qu’ils peuvent utiliser par la suite. Leur durée de vie est limitée.Les JSON Web Tokens (JWT) sont des jetons conformes au standard 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 JWT peuvent être signés à l’aide d’un secret (avec l’algorithme HMAC) ou d’une paire de clés publique/privée avec 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é pour le contenu du jeton.
  • Le corps, aussi appelé le payload, contient des claims d’identité sur un utilisateur. Certains claims portent des noms enregistrés, notamment pour l’émetteur du jeton, le sujet du jeton (la personne visée par les claims) et l’heure d’émission. N’importe quel nombre de claims supplémentaires portant d’autres noms peut être ajouté, mais il faut veiller à ce que le JWT respecte les limites de taille des URL du navigateur.
  • La signature est utilisée par le destinataire d’un JWT pour valider l’intégrité des renseignements transmis 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 spécifiés par l’application.
  2. L’identifiant de l’émetteur du fournisseur OpenID doit correspondre à la valeur de la revendication iss (issuer).
  3. La revendication aud (audience) doit contenir la valeur client_id de l’application. L’ID Token doit être rejeté s’il ne désigne 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’une revendication azp est présente.
  5. Si une revendication azp (authorized party) est présente, l’application doit vérifier que son client_id correspond à la valeur de cette revendication.
  6. L’application doit valider la signature des ID Tokens conformément à JWS, à l’aide de 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 lors de l’enregistrement.
  8. Si le paramètre d’en-tête JWT alg utilise un algorithme fondé sur une MAC, comme HS256, HS384 ou HS512, les octets de la représentation UTF-8 du client_secret correspondant au client_id contenu dans la revendication aud (audience) sont utilisés comme clé pour valider la signature. Pour les algorithmes fondés sur une MAC, le comportement n’est pas spécifié 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 la revendication exp.
  10. La revendication iat peut être utilisée pour rejeter les jetons émis trop loin de l’heure actuelle, ce qui limite la durée pendant laquelle les valeurs nonce doivent être stockées 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 demande d’authentification, une revendication nonce doit être présente et sa valeur doit être vérifiée pour confirmer qu’elle correspond à celle envoyée dans la demande d’authentification. L’application doit vérifier la valeur nonce pour détecter les attaques par rejeu. La méthode précise de détection des attaques par rejeu dépend de l’application.
  12. Si la revendication acr a été demandée, l’application doit vérifier que la valeur de revendication fournie est appropriée.
  13. Si la revendication auth_time a été demandée, soit au moyen d’une demande spécifique de cette revendication, soit à l’aide du paramètre max_age, l’application doit vérifier la valeur de la revendication auth_time et demander une nouvelle authentification si elle détermine qu’un délai trop important 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écurisée.