> ## Documentation Index
> Fetch the complete documentation index at: https://auth0.generaltranslation.app/llms.txt
> Use this file to discover all available pages before exploring further.

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

> Vue d’ensemble de la solution pour le scénario des applications Web classiques.

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.

<div id="identity-management">
  ## Gestion des identités
</div>

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.

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  L’identité en tant que service (Identity-as-Service/IDaaS) est un service basé sur le nuage pour la gestion des identités et des accès. Les services proposés comprennent souvent l’authentification unique (SSO), l’identité fédérée, la gestion des mots de passe, etc.
</Callout>

<div id="which-protocol-to-use">
  ## Quel protocole utiliser?
</div>

La décision suivante concerne le protocole à utiliser : <Tooltip href="/docs/fr-CA/fr-ca/glossary?term=oath2" tip="OAuth 2.0
Cadre d’applications d’autorisation qui définit les protocoles d’autorisation et les flux de production." cta="Voir le glossaire">OAuth 2.0</Tooltip> avec <Tooltip href="/docs/fr-CA/fr-ca/glossary?term=openid" tip="OpenID
Norme ouverte d’authentification qui permet aux applications de vérifier l’identité des utilisateurs sans avoir à collecter leurs informations de connexion." cta="Voir le glossaire">OpenID</Tooltip> Connect (OIDC) ou <Tooltip href="/docs/fr-CA/fr-ca/glossary?term=security-assertion-markup-language" tip="Security Assertion Markup Language (SAML)
Protocole normalisé permettant à deux parties d’échanger des informations d’authentification sans mot de passe." cta="Voir le glossaire">SAML</Tooltip>.

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  Auth0 met en œuvre des protocoles d’identité éprouvés, communs et populaires, à la fois pour les produits Web orientés vers le consommateur (OAuth 2.0, OAuth 1.0, OpenID) et pour les déploiements d’entreprise (SAML, WS-Federation, LDAP). Vous êtes totalement libre d’utiliser celui qui répond le mieux aux besoins de votre entreprise.
</Callout>

**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 (<Tooltip href="/docs/fr-CA/fr-ca/glossary?term=json-web-token" tip="Jeton Web JSON (JWT)
Format standard de jeton d’ID (et souvent de jeton d’accès) utilisé pour représenter en toute sécurité des demandes entre deux parties." cta="Voir le glossaire">JWT</Tooltip>) délivrés via le protocole OAuth 2.0.

<div id="oauth-vs-openid-connect-oidc">
  ### OAuth vs OpenID Connect (OIDC)
</div>

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.

<div id="authentication-flow">
  ## Flux d’authentification
</div>

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.

<Frame>
  <img src="https://mintcdn.com/generaltranslationinc/2HoSdIVVjMeJSj5n/docs/images/fr-ca/cdy7uua7fh8z/5qO4QJH0YW34apsypLXnIk/e27a8cf1469c00d948cc476b11b54300/authz-code-flow.png?fit=max&auto=format&n=2HoSdIVVjMeJSj5n&q=85&s=ed20336990b196f9a1b4baaf0d38c420" alt="undefined" width="2094" height="1140" data-path="docs/images/fr-ca/cdy7uua7fh8z/5qO4QJH0YW34apsypLXnIk/e27a8cf1469c00d948cc476b11b54300/authz-code-flow.png" />
</Frame>

<div id="form-post-response-mode">
  ### 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\&#95;0.html](https://openid.net/specs/oauth-v2-form-post-response-mode-1\&#95;0.html)). :::
</div>

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.

<div id="more-on-tokens">
  ### 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](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).
</div>

Le jeton d’ID, qui est un JWT, est conforme à une norme industrielle (IETF [RFC 7519](https://tools.ietf.org/html/rfc7519)) 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. :::

<div id="how-to-validate-an-id-token">
  ### Comment valider un jeton d’ID
</div>

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.

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  Si vous stockez des jetons d’ID sur votre serveur, faites-le de manière sécurisée.
</Callout>