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

> Découvrez comment Auth0 met en œuvre le cadre d'autorisation OAuth 2.0, y compris les types d'octroi pris en charge et les points de terminaison clés pour sécuriser vos API et vos applications.

# Cadre d'autorisation OAuth 2.0

<Card title="Aperçu">
  Concepts clés

  * Auth0 prend en charge le protocole OAuth 2.0 élaboré par l'Internet Engineering Task Force (IETF).
  * Consultez la spécification OAuth 2.0 pour en savoir plus sur les rôles, les types d'octroi (ou workflows) et les points de terminaison.
</Card>

Le [cadre d'autorisation OAuth 2.0](https://tools.ietf.org/html/rfc6749) est un protocole qui permet à un utilisateur d'accorder à un site Web ou à une application tiers l'accès à ses ressources protégées, sans nécessairement divulguer ses informations d’identification à long terme ni même son identité.

<Tooltip tip="OAuth 2.0 : Cadre d'autorisation qui définit les protocoles et les workflows d'autorisation." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=OAuth">
  OAuth
</Tooltip>

introduit une couche d'autorisation et sépare le rôle du client de celui du

<Tooltip tip="Propriétaire de la ressource : Entité (telle qu'un utilisateur ou une application) capable d'accorder l'accès à une ressource protégée." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=resource+owner">
  propriétaire de la ressource
</Tooltip>

. 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

<Tooltip tip="Serveur de ressources : Serveur hébergeant des ressources protégées. Les serveurs de ressources acceptent et répondent aux requêtes de ressources protégées." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=resource+server">
  serveur de ressources
</Tooltip>

et se voit attribuer un ensemble d'informations d’identification différent de celui du propriétaire de la ressource. Plutôt que d'utiliser les informations d’identification du propriétaire de la ressource pour accéder aux ressources protégées, le client obtient un

<Tooltip tip="Jeton d'accès : Identifiant d'autorisation, sous la forme d'une chaîne opaque ou d'un JWT, utilisé pour accéder à une API." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=access+token">
  jeton d'accès
</Tooltip>

— une chaîne indiquant une portée spécifique, une durée de vie et d'autres attributs d'accès. Les jetons d'accès sont émis aux clients tiers par un

<Tooltip tip="Serveur d'autorisation : Serveur centralisé qui contribue à définir les limites de l'accès d'un utilisateur. Par exemple, votre serveur d'autorisation peut contrôler les données, les tâches et les fonctionnalités disponibles pour un utilisateur." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=authorization+server">
  serveur d'autorisation
</Tooltip>

avec l'approbation du propriétaire de la ressource. Ensuite, le client utilise 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 JSON Web Token (JWT)](/docs/fr-ca/secure/tokens/json-web-tokens/json-web-token-structure). Les autorisations représentées par le jeton d'accès, en termes OAuth, sont appelées [scopes](/docs/fr-ca/get-started/apis/scopes). Lorsqu'une application s'authentifie auprès d'Auth0, elle spécifie les scopes souhaités. Si ces scopes sont autorisés par l'utilisateur, le jeton d'accès représentera ces scopes autorisés.

<div id="roles">
  ## Rôles
</div>

Un flux OAuth 2.0 comprend les rôles suivants :

* **Propriétaire de la ressource** : Entité pouvant accorder l’accès à une ressource protégée. Il s’agit généralement de l’utilisateur final.
* **Serveur de ressources** : Serveur qui héberge les ressources protégées. Il s’agit de l’API à laquelle vous voulez accéder.
* **Client** : Application qui demande l’accès à une ressource protégée au nom du propriétaire de la ressource.
* **Serveur d’autorisation** : Serveur qui authentifie le propriétaire de la ressource et émet des jetons d’accès après avoir obtenu l’autorisation nécessaire. Dans ce cas-ci, il s’agit d’Auth0.

<div id="grant-types">
  ## Types d’octroi
</div>

OAuth 2.0 définit quatre flux permettant d’obtenir un jeton d’accès. Ces flux sont appelés des types d’octroi. [Le choix de celui qui convient à votre situation](/docs/fr-ca/get-started/authentication-and-authorization-flow/which-oauth-2-0-flow-should-i-use) dépend surtout du type d’application.

* [Flux du code d’autorisation](/docs/fr-ca/get-started/authentication-and-authorization-flow/authorization-code-flow) : utilisé par les applications Web exécutées sur un serveur. Ce flux est aussi utilisé par les applications mobiles au moyen de la [technique de clé de preuve pour l’échange de code (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 axées sur JavaScript (applications monopage) qui s’exécutent dans le navigateur de l’utilisateur.
* [Flux de mot de passe du propriétaire de la ressource](/docs/fr-ca/get-started/authentication-and-authorization-flow/resource-owner-password-flow) : utilisé par les applications hautement fiables.
* [Flux des informations d’identification du client](/docs/fr-ca/get-started/authentication-and-authorization-flow/client-credentials-flow) : utilisé pour la communication machine à machine.

La spécification prévoit aussi un mécanisme d’extensibilité permettant de définir des types d’octroi supplémentaires. Pour en savoir plus sur le fonctionnement de chaque type d’octroi et sur les situations où l’utiliser, consultez [les flux d’authentification et d’autorisation](/docs/fr-ca/get-started/authentication-and-authorization-flow).

<div id="endpoints">
  ## Endpoints
</div>

OAuth 2.0 utilise deux endpoints : `/authorize` et `/oauth/token`.

<div id="authorization-endpoint">
  ### Point de terminaison d’autorisation
</div>

Le point de terminaison `/authorize` sert à 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 voulez vous connecter à un service avec votre compte Google. D’abord, le service vous redirige vers Google afin de vous authentifier (si vous n’êtes pas déjà connecté), puis un écran de consentement s’affiche, où l’on vous demandera 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 grant exécuter.                                                                                                                                                                                                                                                                                                                                                                                                                                              |
| `response_mode` | (Facultatif) Indique comment le résultat de la requête d’autorisation est mis en forme. Valeurs :<br />- `query` : pour le grant Authorization Code. `302 Found` déclenche une redirection.<br />- `fragment` : pour le grant Implicit. `302 Found` déclenche une redirection.<br />- `form_post` : `200 OK` avec les paramètres de réponse intégrés dans un formulaire HTML comme paramètres masqués.<br />- `web_message` : pour l’authentification silencieuse. Utilise la messagerie Web HTML5. |
| `client_id`     | L’ID de l’application qui demande l’autorisation.                                                                                                                                                                                                                                                                                                                                                                                                                                                   |
| `redirect_uri`  | Contient une URL. Une réponse réussie de ce point de terminaison entraîne une redirection vers cette URL.                                                                                                                                                                                                                                                                                                                                                                                           |
| `scope`         | Une liste de permissions séparées par des espaces dont l’application a besoin.                                                                                                                                                                                                                                                                                                                                                                                                                      |
| `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 dans le cadre du `redirect_uri`.                                                                                                                                                                                                                                                                                                                          |
| `connection`    | Spécifie le type de connexion pour les connexions Passwordless                                                                                                                                                                                                                                                                                                                                                                                                                                      |

Vous pouvez configurer des paramètres de requête personnalisés lorsque votre application effectue la requête initiale vers le 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 de l’expérience <Tooltip tip="Universal Login : votre application redirige vers Universal Login, hébergé sur le serveur d’autorisation d’Auth0, afin de vérifier l’identité d’un utilisateur." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=Universal+Login">Universal Login</Tooltip>.

Vous devez activer ID First pour utiliser le paramètre `connection`. Pour en savoir plus sur le paramètre `connection` et l’expérience Universal Login, consultez [Passwordless for Universal Login](/docs/fr-ca/authenticate/passwordless/passwordless-with-universal-login).

Les paramètres de requête préfixés par `ext-` apparaissent automatiquement dans le [contexte du modèle de page](/docs/fr-ca/customize/login-pages/universal-login/customize-templates#custom-query-parameters).

Ce point de terminaison est utilisé par les types de grant Authorization Code et Implicit. Le serveur d’autorisation doit savoir quel type de grant l’application veut utiliser, puisque cela influe sur le type d’identifiant qu’il émettra :

* Pour le grant Authorization Code, il émettra un code d’autorisation (qui pourra ensuite être échangé contre un jeton d’accès au point de terminaison `/oauth/token`).
* Pour le grant Implicit, il émettra un jeton d’accès, qui est une chaîne opaque (ou un <Tooltip tip="JSON Web Token (JWT) : format standard de ID Token (et souvent de jeton d’accès) utilisé pour représenter de façon sécuritaire des revendications entre deux parties." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=JWT">JWT</Tooltip> dans une mise en œuvre Auth0) qui indique quelle application a été autorisée à quelles permissions (scopes), et par qui.

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

* Pour le grant Authorization Code, utilisez `response_type=code` pour inclure le code d’autorisation.
* Pour le grant Implicit, utilisez `response_type=token` pour inclure un jeton d’accès. Une autre possibilité est d’utiliser `response_type=id_token token` pour inclure à la fois un jeton d’accès et un <Tooltip tip="ID Token : identifiant destiné au client lui-même, plutôt qu’à l’accès à une ressource." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=ID+token">ID token</Tooltip>.

Un ID token est un JWT qui contient des renseignements sur l’utilisateur connecté. Il a été introduit par <Tooltip tip="OpenID : norme ouverte d’authentification qui permet aux applications de vérifier l’identité des utilisateurs sans recueillir ni stocker les renseignements de connexion." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=OpenID">OpenID</Tooltip> Connect (OIDC).

La spécification [OAuth 2.0 Multiple Response Type Encoding Practices](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 requête d’autorisation est mis en forme. Ce paramètre s’appelle `response_mode`. Il est facultatif et peut prendre les valeurs suivantes :

| Valeur        | Description                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      |
| ------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `query`       | Il s’agit du mode par défaut pour le grant Authorization Code. Une réponse réussie est `302 Found`, ce qui déclenche une redirection vers le `redirect_uri`. Les paramètres de la réponse sont intégrés à la composante 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 du mode par défaut pour le grant Implicit. Une réponse réussie est `302 Found`, ce qui déclenche une redirection vers le `redirect_uri` (qui est un paramètre de requête). Les paramètres de la réponse sont intégrés à la composante de 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&token_type=Bearer&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 sous forme de `params` masqués. L’élément `action` du formulaire correspond au `redirect_uri` et l’attribut `onload` est configuré pour soumettre le formulaire. Une fois le HTML chargé par le navigateur, une redirection vers le `redirect_uri` est effectuée.                                                                                                           |
| `web_message` | Ce mode de réponse est défini dans la [spécification OAuth 2.0 Web Message Response Mode](https://tools.ietf.org/html/draft-sakimura-oauth-wmrm-00). Il utilise la messagerie Web HTML5 au lieu d’une redirection pour la réponse d’autorisation provenant du point de terminaison /authorization. Cela 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 **Allowed Web Origins** des [paramètres de l’application](https://manage.auth0.com/#/applications/\{yourClientId}/settings) Auth0. |

<div id="token-endpoint">
  ### Point de terminaison de jeton
</div>

Le point de terminaison `/oauth/token` est utilisé par l’application pour obtenir un jeton d’accès ou un <Tooltip tip="Jeton d’actualisation : jeton utilisé pour obtenir un nouveau jeton d’accès sans obliger les utilisateurs à se connecter de nouveau." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=refresh+token">jeton d’actualisation</Tooltip>. Il est utilisé dans tous les flux, sauf le flux implicite, car dans ce cas, un jeton d’accès est émis directement.

* Dans le flux de code d’autorisation, l’application échange le code d’autorisation obtenu du point de terminaison d’autorisation contre un jeton d’accès.
* Dans le flux des informations d’identification du client et l’échange d’octroi des informations d’identification par mot de passe du propriétaire de la ressource, l’application s’authentifie au moyen d’un ensemble d’informations d’identification, puis obtient un jeton d’accès.

<div id="state-parameters">
  ## Paramètres d’état
</div>

Les protocoles d’autorisation fournissent un paramètre `state` qui vous permet de rétablir l’état antérieur de votre application. Le paramètre `state` conserve l’objet d’état défini par le client dans la requête d’autorisation et le rend accessible au client dans la réponse. La principale raison d’utiliser le paramètre `state` est de réduire les risques d’attaques CSRF. Consultez [Utiliser les paramètres d’état d’OAuth 2.0](/docs/fr-ca/secure/attack-protection/state-parameters) pour en savoir plus.

<div id="learn-more">
  ## En savoir plus
</div>

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