> ## Documentation Index
> Fetch the complete documentation index at: https://docs-dev-docs-event-stream-action-templates.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Cadre d’applications Authorization OAuth 2.0

> Découvrez comment Auth0 fonctionne avec le cadre d’applications Authorization OAuth 2.0.

<Card title="Vue d’ensemble">
  Principaux concepts

  * Auth0 prend en charge le protocole OAuth 2.0 rédigé par l’IETF (Internet Engineering Task Force).
  * Découvrez les rôles, types d’autorisation (ou flux de production) et points de terminaison de la spécification OAuth 2.0.
</Card>

Le cadre d’applications Authorization [OAuth 2.0](https://tools.ietf.org/html/rfc6749) est un protocole qui permet à un utilisateur d’accorder à un site Web ou à une application tierce l’accès aux ressources protégées de l’utilisateur, sans nécessairement révéler ses identifiants à long terme ou même son identité.

<Tooltip href="/docs/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</Tooltip> introduit une couche d’autorisation et sépare le rôle du client de celui du propriétaire de la ressource. Dans OAuth, le client demande l’accès aux ressources contrôlées par le propriétaire de la ressource et hébergées par le serveur de ressources et reçoit un ensemble d’identifiants différent de celui du propriétaire de la ressource. Au lieu d’utiliser les identifiants du propriétaire de la ressource pour accéder aux ressources protégées, le client obtient un jeton d’accès, une chaîne indiquant une permission, une durée de vie et d’autres attributs d’accès spécifiques. Les jetons d’accès sont émis aux clients tiers par un serveur d’autorisation avec l’approbation du propriétaire de la ressource. Le client utilise ensuite le jeton d’accès pour accéder aux ressources protégées hébergées par le serveur de ressources.

Auth0 génère des jetons d’accès pour les scénarios d’autorisation d’API, au [format jeton Web JSON (JWT)](/docs/fr-ca/secure/tokens/json-web-tokens/json-web-token-structure). Les autorisations représentées par le jeton d’accès, dans la terminologie OAuth, sont connues sous le nom de [permissions](/docs/fr-ca/get-started/apis/scopes). Lorsqu’une application s’authentifie avec Auth0, elle spécifie les permissions qu’elle souhaite obtenir. Si ces permissions sont autorisées par l’utilisateur, le jeton d’accès les représentera.

## Rôles

Un flux OAuth 2.0 comprend les rôles suivants :

* **<Tooltip href="/docs/fr-ca/glossary?term=resource-owner" tip="Propriétaire de ressources
  Entité (telle qu’un utilisateur ou une application) capable d’accorder l’accès à une ressource protégée." cta="Voir le glossaire">Resource Owner</Tooltip> (Propriétaire de ressource)** : Une entité pouvant accorder l’accès à une ressource protégée. Il s’agit généralement de l’utilisateur final.
* **<Tooltip href="/docs/fr-ca/glossary?term=resource-server" tip="Serveur de ressources
  Serveur hébergeant des ressources protégées. Les serveurs de ressources traitent les requêtes pour des ressources sécurisées et y répondent." cta="Voir le glossaire">Resource Server</Tooltip> (Serveur de ressources)** : Serveur hébergeant les ressources protégées. Il s’agit de l’API à laquelle vous souhaitez accéder.
* **Client** : Application demandant l’accès à une ressource protégée au nom du propriétaire de ressource.
* **<Tooltip href="/docs/fr-ca/glossary?term=authorization-server" tip="Serveur d’autorisations :
  Serveur centralisé qui contribue à définir les limites de l’accès d’un utilisateur. Par exemple, votre serveur d’autorisations peut contrôler les données, les tâches et les fonctionnalités accessibles à un utilisateur. Un serveur d’autorisation ne sert pas à authentifier les utilisateurs. Cette tâche incombe au serveur d’authentification, qui est chargé de vérifier l’identité d’un utilisateur." cta="Voir le glossaire">Authorization Server</Tooltip> (Serveur d’autorisations)** : Serveur qui authentifie le propriétaire de la ressource et émet des jetons d’accès après avoir obtenu l’autorisation appropriée. Dans ce cas, Auth0.

## Types d’autorisation

OAuth 2.0 définit quatre flux pour obtenir un jeton d’accès. Ces flux sont appelés types d’autorisation. [Le choix de la solution la plus adaptée à vos besoins](/docs/fr-ca/get-started/authentication-and-authorization-flow/which-oauth-2-0-flow-should-i-use) dépend principalement du type d’application.

* [Flux de code d’autorisation](/docs/fr-ca/get-started/authentication-and-authorization-flow/authorization-code-flow) : utilisé par les applications Web s’exécutant sur un serveur. Il est également utilisé par les applications mobiles, à l’aide de la [technique de Proof Key for Code Exchange (PKCE)](/docs/fr-ca/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce).
* [Flux implicite avec Form Post](/docs/fr-ca/get-started/authentication-and-authorization-flow/implicit-flow-with-form-post) : utilisé par les applications centrées sur JavaScript (applications Web à page unique) qui s’exécutent sur le navigateur de l’utilisateur.
* [Flux de mot de passe du propriétaire de ressource](/docs/fr-ca/get-started/authentication-and-authorization-flow/resource-owner-password-flow) : utilisé par les applications hautement fiables.
* [Flux des identifiants client](/docs/fr-ca/get-started/authentication-and-authorization-flow/client-credentials-flow) : utilisé pour les communications entre machines.

La spécification OAuth 2.0 offre également un mécanisme d’extensibilité permettant de définir des types d’autorisations supplémentaires. Pour en savoir plus sur le fonctionnement de chaque type d’autorisation et sur le moment où il doit être utilisé, consultez [Authentication and Authorization Flows (Flux d’authentification et d’autorisation)](/docs/fr-ca/get-started/authentication-and-authorization-flow).

## Points de terminaison

OAuth 2.0 utilise deux points de terminaison : le point de terminaison `/authorize` et le point de terminaison `/oauth/token`.

### Point de terminaison d’autorisation

Le point de terminaison `/authorize` est utilisé pour interagir avec le propriétaire de la ressource et obtenir l’autorisation d’accéder à la ressource protégée. Pour mieux comprendre, imaginez que vous souhaitiez vous connecter à un service en utilisant votre compte Google. Tout d’abord, le service vous redirige vers Google afin de vous authentifier (si vous n’êtes pas déjà connecté), puis vous obtenez un écran de consentement, dans lequel il vous est demandé d’autoriser le service à accéder à certaines de vos données (ressources protégées); par exemple, votre adresse courriel et votre liste de contacts.

Les paramètres de requête du point de terminaison `/authorize` sont les suivants :

| Paramètre       | Description                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       |
| --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `response_type` | Indique au serveur d’autorisation quel type d’autorisation accorder.                                                                                                                                                                                                                                                                                                                                                                                                                              |
| `response_mode` | (facultatif) Comment est formaté le résultat de la requête d’autorisation. Valeurs :<br />- `query` : pour l’octroi du code d’autorisation. `302 Found` déclenche une redirection.<br />- `fragment` : pour un octroi implicite. `302 Found` déclenche une redirection.<br />- `form_post` : `200 OK` avec des paramètres de réponse intégrés dans un formulaire HTML en tant que paramètres cachés.<br />- `web_message` : Pour l’authentification silencieuse. Utilise la messagerie web HTML5. |
| `client_id`     | L’identifiant de l’application qui demande l’autorisation.                                                                                                                                                                                                                                                                                                                                                                                                                                        |
| `redirect_uri`  | Contient une URL. Une réponse positive de ce point de terminaison entraîne une redirection vers cette URL.                                                                                                                                                                                                                                                                                                                                                                                        |
| `scope`         | Une liste d’autorisations délimitées par des espaces dont a besoin l’application.                                                                                                                                                                                                                                                                                                                                                                                                                 |
| `state`         | Une valeur opaque, utilisée à des fins de sécurité. Si ce paramètre de requête est défini dans la requête, il est renvoyé à l’application en tant que partie du « redirect\_uri ».                                                                                                                                                                                                                                                                                                                |
| `connection`    | Spécifie le type de connexion pour les connexions sans mot de passe                                                                                                                                                                                                                                                                                                                                                                                                                               |

Vous pouvez configurer des paramètres de requête personnalisés lorsque votre application effectue l’appel initial au point de terminaison `/authorize` pour authentifier un utilisateur. Vous pouvez utiliser des paramètres de requête personnalisés pour fournir un contexte supplémentaire au modèle de page pour l’expérience de connexion universelle.

Vous devez activer l’option ID First pour utiliser le paramètre `connection`. Pour plus d’informations sur le paramètre `connection` et l’expérience Connexion universelle, consultez [Connexion universelle sans mot de passe](/docs/fr-ca/authenticate/passwordless/passwordless-with-universal-login).

Les paramètres de requête précédés du préfixe `ext-` apparaissent automatiquement dans le [contexte du modèle de page](https://auth0.com/docs/customize/universal-login-pages/universal-login-page-templates#custom-query-parameters).

Ce point de terminaison est utilisé par les types d’autorisation Code d’autorisation et Implicite. Le serveur d’autorisation doit savoir quel type d’octroi l’application souhaite utiliser, pour déterminer le type de justificatif à émettre :

* Pour l’octroi d’un code d’autorisation, il émettra un code d’autorisation (qui pourra ensuite être échangé contre un jeton d’accès au point de terminaison `/oauth/token`).
* Pour l’octroi implicite, il émettra un jeton d’accès, une chaîne opaque (ou un <Tooltip href="/docs/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> dans une implémentation Auth0) qui indique qui a autorisé quelles permissions (scopes) à quelle application.

Pour indiquer au serveur d’autorisation le type d’autorisation à utiliser, le paramètre de requête `response_type` est utilisé comme suit :

* Pour l’octroi d’un code d’autorisation, utilisez `response_type=code` pour inclure le code d’autorisation.
* Pour l’octroi implicite, utilisez `response_type=token` pour inclure un jeton d’accès. Une solution de rechange consiste à utiliser le `jeton response_type=id_token` pour inclure à la fois un jeton d’accès et un jeton d’ID.

Un jeton d’ID est un JWT qui contient des informations sur l’utilisateur connecté. Ce type de jeton a été introduit par <Tooltip href="/docs/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).

La spécification [Pratiques d’encodage des types de réponses multiples OAuth 2.0](https://openid.net/specs/oauth-v2-multiple-response-types-1_0.html) a ajouté un paramètre qui précise comment le résultat de la demande d’autorisation est formaté. Ce paramètre est appelé `response_mode`. Il est facultatif et peut avoir les valeurs suivantes :

| Valeur        | Description                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       |
| ------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `query`       | C’est la valeur par défaut pour l’octroi du code d’autorisation. Une réponse réussie est `302 Found` qui déclenche une redirection vers le `redirect_uri`. Les paramètres de réponse sont intégrés dans le composant de requête (la partie après `?`) du `redirect_uri` dans l’en-tête `Location`.<br />Par exemple :<br />`HTTP/1.1 302 Found`<br />`Location : https://my-redirect-uri.callback?code=js89p2x1` où le code d’autorisation est `js89p21`.                                                                                                                                                                         |
| `fragment`    | Il s’agit de la valeur par défaut de l’autorisation implicite. Une réponse réussie est `302 Found`, qui déclenche une redirection vers le `redirect_uri` (qui est un paramètre de requête). Les paramètres de réponse sont intégrés dans le composant fragment (la partie après `#`) du `redirect_uri` dans l’en-tête `Location`.<br />Par exemple :<br />`HTTP/1.1 302 Found`<br />`Location : https://my-redirect-uri/callback#access_token=eyB...78f&amp;token_type=Bearer&amp;expires_in=3600`.                                                                                                                               |
| `form_post`   | Le mode de réponse est défini par la spécification [OAuth 2.0 Form Post Response Mode](https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html). Une réponse réussie est `200 OK` et les paramètres sont intégrés dans un formulaire HTML en tant que paramètres dissimulés. L’action du formulaire est le `redirect_uri` et l’attribut `onload` est configuré pour soumettre le formulaire. Une fois que le HTML est chargé par le navigateur, une redirection vers le `redirect_uri` est effectuée.                                                                                                                  |
| `web_message` | Ce mode de réponse est défini dans [Spécification du mode de réponse aux messages Web OAuth 2.0](https://tools.ietf.org/html/draft-sakimura-oauth-wmrm-00). Il utilise la messagerie Web HTML5 au lieu de la redirection pour la réponse d’autorisation du point de terminaison /authorization. Ceci est particulièrement utile lors de l’utilisation de l’authentification silencieuse. Pour utiliser ce mode de réponse, vous devez enregistrer l’URL de votre application dans le champ **Origines Web autorisées** de vos [paramètres d’application](https://manage.auth0.com/#/applications/\{yourClientId}/settings) Auth0. |

### Point de terminaison du jeton

Le point de terminaison `/oauth/token` est utilisé par l’application pour obtenir un jeton d’accès ou un jeton d’actualisation. Tous les flux l’utilisent, à l’exception du flux implicite, car dans ce cas, un jeton d’accès est émis directement.

* Dans le flux du code d’autorisation, l’application échange le code d’autorisation qu’elle a obtenu du point de terminaison d’autorisation contre un jeton d’accès.
* Dans le Flux des identifiants client et l’échange d’informations d’identification du mot de passe du propriétaire de ressource, l’application s’authentifie à l’aide d’un ensemble d’informations d’identification et obtient ensuite un jeton d’accès.

## Paramètres d’état

Les protocoles d’autorisation fournissent un paramètre `state` qui vous permet de restaurer l’état précédent de votre application. Le paramètre `state` conserve un objet d’état défini par le client dans la requête d’autorisation et le rend disponible pour le client dans la réponse. La principale raison d’utiliser le paramètre state est de réduire les attaques par falsification de requête intersite (CSRF). Consultez [Use OAuth 2.0 State Parameters (Utiliser les paramètres d’état OAuth 2.0)](/docs/fr-ca/secure/attack-protection/state-parameters) pour plus de détails.

## En savoir plus

* [Prévenir les attaques et rediriger les utilisateurs avec les paramètres d’état OAuth 2.0](/docs/fr-ca/secure/attack-protection/state-parameters)
* [Quel flux OAuth 2.0 dois-je utiliser?](/docs/fr-ca/get-started/authentication-and-authorization-flow/which-oauth-2-0-flow-should-i-use)