Présentation de la solution (applications Web + SSO)

Dans cette section, nous aborderons la solution que nous mettons en œuvre, y compris les 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’identité en tant que service (IDaaS). Cette décision s’explique par le fait que l’entreprise ne souhaitait pas consacrer de ressources à la formation, à la mise en œuvre et à la maintenance de la gestion des identités et des accès. En outre, l’entreprise prévoit de développer cette solution à l’avenir, en ajoutant éventuellement une application mobile native et une API pour envoyer les feuilles de temps approuvées vers leurs systèmes internes. Auth0 offre la flexibilité nécessaire pour intégrer de tels changements dans leur architecture avec un minimum d’effort.

Quel protocole utiliser?

La décision suivante concerne le protocole à utiliser : OAuth 2.0 avec OpenID Connect (OIDC) ou SAML.

OpenID Connect est un protocole d’authentification basé sur la famille de spécifications OAuth 2.0. Il utilise de simples jetons d’identité JSON (JWT) délivrés via le protocole OAuth 2.0.

OAuth vs OpenID Connect (OIDC)

OAuth 2.0 et OpenID Connect (OIDC) sont souvent confondus, mais ils sont différents. 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 vous donner accès à vos fichiers. Si vous acceptez, le site web sera autorisé à accéder à vos fichiers depuis Dropbox. Au fond, OAuth 2.0 concerne l’accès aux ressources et leur partage. En revanche, OpenID Connect est une simple couche d’identité construite au-dessus du protocole OAuth 2.0. Il vous permet d’avoir un seul connexion pour plusieurs sites. Chaque fois que vous devez vous connecter à un site web à l’aide de l’OIDC, vous êtes redirigé vers votre site OpenID où vous vous connectez, puis renvoyé vers le site web. L’OIDC concerne essentiellement l’authentification des utilisateurs.

SAML est un protocole basé sur XML, qui fournit à la fois l’authentification et l’autorisation entre des parties de confiance.

Par rapport à 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’un des arguments les plus convaincants pour adopter SAML) n’est pas non plus requise dans ce cas. Si elle le devient, Auth0 peut la gérer facilement, tout comme AD (qui utilise LDAP).

Pour ces raisons, ExampleCo utilisera OpenID Connect pour sa mise en œuvre.

Flux d’authentification

OpenID Connect prend en charge plusieurs flux d’authentification. Puisque notre scénario implique une application Web classique, nous utiliserons le flux de code d’autorisation.

Le flux de connexion est le suivant :

  1. L’application Web (appelée Client dans la terminologie OIDC) initie la demande d’authentification en redirigeant le user-agent (navigateur) vers Auth0 (le serveur d’autorisations dans la terminologie OIDC).

  2. Auth0 authentifie l’utilisateur (via le user-agent). La première fois que l’utilisateur passe par ce flux, une page de consentement s’affiche, où sont énumérées les autorisations qui seront accordées à l’application (p. ex., poster des messages, répertorier des contacts). L’utilisateur se connecte au service (à moins qu’il ne soit déjà connecté) et autorise l’accès à l’application.

  3. Si l’utilisateur autorise l’accès, Auth0 redirige le user-agent vers l’application, avec un code d’autorisation dans la chaîne de requête.

  4. L’application envoie le code d’autorisation à Auth0, ainsi que les informations d’identification de l’application (client_id et client_secret), et demande un jeton.

  5. Auth0 authentifie l’application (à l’aide de l’identifiant et du secret du client) et valide le code d’autorisation. S’il est valide, Auth0 répond par un jeton d’identification.

undefined

Mode de réponse à l’envoi d’un formulaire Une autre option est d’utiliser le __OAuth 2.0 Form Post Response Mode__ 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 le jeton d’ID, au lieu du code d’autorisation, tandis que le paramètre `response_mode=form_post` encode le jeton d’ID avec le reste des paramètres de la réponse d’autorisation en tant que valeurs de formulaire HTML qui sont soumises automatiquement dans le User Agent. De cette façon, vous pouvez avoir un flux d’authentification optimisé (pas besoin d’échanger le code pour un jeton d’ID), mais vous devez vous assurer qu’il est pris en charge par la technologie que vous utilisez pour mettre en œuvre votre application (le logiciel médiateur ASP .NET Core le prend en charge). Pour plus de détails, consultez la [spécification Mode de réponse à l’envoi d’un formulaire OAuth 2.0] (https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html). :::

Le jeton d’ID (généralement appelé id_token dans les exemples de code) est un jeton Web JSON (JWT) qui contient des données d'identité. Il est consommé par l'application et utilisé pour obtenir des informations de l'utilisateur comme son nom, son courriel, et ainsi de suite, généralement utilisées pour l'affichage de l'interface utilisateur.

En savoir plus sur les jetons Les jetons sont des chaînes alphanumériques utilisées dans le cadre d’une authentification basée sur des jetons. Ils permettent aux utilisateurs de s’authentifier une fois avec un nom d’utilisateur et un mot de passe et d’obtenir en retour un jeton qu’ils peuvent utiliser à partir de ce moment-là. Ils ont une durée de vie limitée. Les __Jetons Web JSON (JWT)__ sont des jetons conformes à la [JSON Web Token Standard] (https://tools.ietf.org/html/rfc7519) et contiennent des informations sur une identité sous la forme de demandes. Ils sont autonomes en ce sens qu’il n’est pas nécessaire pour le destinataire 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 utilisant l’algorithme __RSA__. Vous pouvez trouver plus d’informations sur jeton Web JSON (JWT) [ici] (/tokens/concepts/jwts).

Le jeton d’ID, qui est un JWT, est conforme à une norme industrielle (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, également appelé « données utiles », contient des informations sur l’identité de l’utilisateur. Certaines réclamations portent des noms enregistrés, par exemple pour l’émetteur du jeton, le sujet du jeton (qui fait l’objet des réclamations) et le moment de l’émission. Il est possible d’ajouter un nombre quelconque de réclamations supplémentaires avec d’autres noms, mais il faut veiller à ce que le JWT ne dépasse pas les limites de taille du navigateur pour les URL.
  • La signature est utilisée par le destinataire d’un JWT pour valider l’intégrité des informations transmises dans le JWT. :::

Comment valider un jeton d’ID

La validation d’un jeton d’ID nécessite plusieurs étapes :

  1. Si le jeton d’ID est chiffré, il faut le déchiffrer en utilisant les clés et les algorithmes précisés par l’application.

  2. L’identifiant de l’émetteur pour le fournisseur OpenID doit correspondre à la valeur de la demande iss (émetteur).

  3. La demande aud (audience) doit contenir la valeur client_id de l'application. Le jeton d'ID doit être rejeté s'il ne mentionne pas l'application en tant qu'une audience valide ou s'il contient des audiences supplémentaires auxquelles l'application n'accorde pas sa confiance.

  4. Si le jeton d’identification contient plusieurs audiences, l’application doit vérifier qu’une demande azp est présente.

  5. Si une demande azp (partie autorisée) est présente, l’application doit vérifier que son client_id correspond à la valeur de la demande.

  6. L’application doit valider la signature des jetons d’ID conformément à JWS en utilisant l’algorithme spécifié dans le paramètre d’en-tête alg du JWT. L’application doit utiliser les clés fournies par l’émetteur.

  7. La valeur alg doit être celle par défaut de RS256 ou de 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 alg du JWT utilise un algorithme de type MAC comme HS256, HS384, ou HS512, les octets de la représentation UTF-8 du client_secret correspondant au client_id contenu dans la demande aud (audience) sont utilisés comme clé de validation de la signature. Pour les algorithmes de type MAC, le comportement n’est pas précisé si aud est à valeurs multiples ou si une valeur azp est présente, différente de la valeur aud.

  9. L’heure indiquée doit être antérieure à l’heure représentée par la demande exp.

  10. La demande iat peut être utilisée pour rejeter les jetons qui ont été émis à une date trop éloignée de l’heure actuelle, ce qui limite la durée pendant laquelle les nombres aléatoires doivent être stockés pour prévenir les attaques. La plage acceptable est propre à l’application.

  11. Si une valeur nonce a été envoyée dans la requête d’authentification, une demande nonce doit être présente pour s’assurer 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 du nonce pour détecter les attaques par réinsertion. La méthode précise de détection des attaques par réinsertion est propre à l’application.

  12. Si la demande acr a été émise, l’application doit vérifier que la valeur de l’allégation affirmée est appropriée.

  13. Si la demande auth_time a été émise, soit par une demande particulière pour cette allégation, soit en utilisant le paramètre max_age, l’application doit vérifier la valeur de la demande auth_time et demander une réauthentification si elle détermine que trop de temps s’est écoulé depuis la dernière authentification de l’utilisateur final.