> ## 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 fonctionne avec le cadre d'autorisation OAuth 2.0.

# Cadre d'autorisation OAuth 2.0

<Card title="Overview">
  Concepts clés

  * Auth0 prend en charge le protocole OAuth 2.0 rédigé par l'Internet Engineering Task Force (IETF).
  * Découvrez les rôles, les types d'octroi (ou flux) et les points de terminaison de la spécification OAuth 2.0.
</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 aux ressources protégées de l'utilisateur, sans nécessairement révéler 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 flux d'autorisation." cta="Voir le glossaire" href="/fr-CA/docs/glossary?term=OAuth">
  OAuth
</Tooltip>

introduit une couche d'autorisation et sépare le rôle de l'application 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="/fr-CA/docs/glossary?term=resource+owner">
  propriétaire de la ressource
</Tooltip>

. Dans OAuth, l'application 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 les demandes d'accès aux ressources protégées et y répondent." cta="Voir le glossaire" href="/fr-CA/docs/glossary?term=resource+server">
  serveur de ressources
</Tooltip>

et reçoit 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, l'application obtient un

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

— une chaîne indiquant un scope particulier, une durée de vie et d'autres attributs d'accès. Les jetons d'accès sont émis aux applications tierces 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 accessibles à un utilisateur." cta="Voir le glossaire" href="/fr-CA/docs/glossary?term=authorization+server">
  serveur d'autorisation
</Tooltip>

avec l'approbation du propriétaire de la ressource. L'application 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 JSON web token (JWT)](/fr-CA/docs/secure/tokens/json-web-tokens/json-web-token-structure). Les permissions représentées par le jeton d'accès, en termes OAuth, sont connues sous le nom de [scopes](/fr-CA/docs/get-started/apis/scopes). Lorsqu'une application s'authentifie auprès d'Auth0, elle spécifie les scopes qu'elle souhaite. 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 souhaitez accéder.
* **Application** : 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 appropriée. Dans ce cas, 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 cas](/fr-CA/docs/get-started/authentication-and-authorization-flow/which-oauth-2-0-flow-should-i-use) dépend surtout de votre type d’application.

* [Flux du code d’autorisation](/fr-CA/docs/get-started/authentication-and-authorization-flow/authorization-code-flow) : utilisé par les applications Web exécutées sur un serveur. Il est également utilisé par les applications mobiles au moyen de la [technique Proof Key for Code Exchange (PKCE)](/fr-CA/docs/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce).
* [Flux implicite avec envoi de formulaire](/fr-CA/docs/get-started/authentication-and-authorization-flow/implicit-flow-with-form-post) : utilisé par les applications axées sur JavaScript (applications monopages) exécutées dans le navigateur de l’utilisateur.
* [Flux avec mot de passe du propriétaire de la ressource](/fr-CA/docs/get-started/authentication-and-authorization-flow/resource-owner-password-flow) : utilisé par les applications hautement fiables.
* [Flux des informations d’identification de l’application](/fr-CA/docs/get-started/authentication-and-authorization-flow/client-credentials-flow) : utilisé pour les communications de machine à machine.

La spécification fournit également 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 le moment où il doit être utilisé, consultez [Flux d’authentification et d’autorisation](/fr-CA/docs/get-started/authentication-and-authorization-flow).

<div id="endpoints">
  ## Points de terminaison
</div>

OAuth 2.0 utilise deux points de terminaison : `/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 souhaitez vous connecter à un service à l’aide de 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 demande d’autoriser le service à accéder à certaines de vos données (ressources protégées) ; par exemple, votre adresse de 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’octroi exécuter.                                                                                                                                                                                                                                                                                                                                                                                                                                       |
| `response_mode` | (Facultatif) Indique comment le résultat de la requête d’autorisation est mis en forme. Valeurs :<br />- `query` : pour l’octroi de code d’autorisation. `302 Found` déclenche une redirection.<br />- `fragment` : pour l’octroi implicite. `302 Found` déclenche une redirection.<br />- `form_post` : `200 OK` avec les paramètres de réponse intégrés à un formulaire HTML comme paramètres caché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 délimité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 `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 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 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="/fr-CA/docs/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](/fr-CA/docs/authenticate/passwordless/passwordless-with-universal-login).

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

Ce point de terminaison est utilisé par les types d’octroi de code d’autorisation et implicite. Le serveur d’autorisation doit savoir quel type d’octroi l’application veut utiliser, puisque cela influe sur le type de justificatif qu’il émettra :

* Pour l’octroi de 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, 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 des revendications de façon sécurisée entre deux parties." cta="Voir le glossaire" href="/fr-CA/docs/glossary?term=JWT">JWT</Tooltip> dans une implémentation Auth0) qui indique qui a autorisé quelles permissions (scopes) à quelle application.

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

* Pour l’octroi de 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 autre possibilité consiste à utiliser `response_type=id_token token` pour inclure à la fois un jeton d’accès et un <Tooltip tip="ID Token : identifiant destiné à l’application cliente elle-même, plutôt qu’à l’accès à une ressource." cta="Voir le glossaire" href="/fr-CA/docs/glossary?term=ID+token">jeton d’identité</Tooltip>.

Un jeton d’identité 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="/fr-CA/docs/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 l’octroi de code d’autorisation. Une réponse réussie est `302 Found`, ce qui déclenche une redirection vers le `redirect_uri`. Les paramètres de réponse sont inclus dans 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 l’octroi implicite. Une réponse réussie est `302 Found`, ce qui déclenche une redirection vers le `redirect_uri` (qui est un paramètre de la requête). Les paramètres de réponse sont inclus dans 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 à un formulaire HTML en tant que paramètres masqués. L’attribut `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 transmettre la réponse d’autorisation depuis le point de terminaison /authorization. Cela est particulièrement utile lorsque vous utilisez 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) dans 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 reconnecter." cta="Voir le glossaire" href="/fr-CA/docs/glossary?term=refresh+token">jeton d’actualisation</Tooltip>. Il est utilisé dans tous les flux, sauf le flux implicite, puisque 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 auprès du point de terminaison d’autorisation contre un jeton d’accès.
* Dans le flux d’identifiants du client et l’échange de subvention avec identifiants du mot de passe du propriétaire de la ressource, l’application s’authentifie à l’aide d’un ensemble d’identifiants, puis obtient un jeton d’accès.

<div id="state-parameters">
  ## Paramètres `state`
</div>

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 l’application dans la requête d’autorisation et le rend accessible à l’application dans la réponse. La principale raison d’utiliser le paramètre `state` est d’atténuer les attaques CSRF. Consultez [Utiliser les paramètres `state` d’OAuth 2.0](/fr-CA/docs/secure/attack-protection/state-parameters) pour en savoir plus.

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

* [Prévenez les attaques et redirigez les utilisateurs à l’aide des paramètres state d’OAuth 2.0](/fr-CA/docs/secure/attack-protection/state-parameters)
* [Quel flux OAuth 2.0 devrais-je utiliser ?](/fr-CA/docs/get-started/authentication-and-authorization-flow/which-oauth-2-0-flow-should-i-use)