> ## 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 déterminer le flux OAuth 2.0 qui convient à votre cas d’utilisation.

# Quel flux OAuth 2.0 devrais-je utiliser ?

Le [cadre d’autorisation OAuth 2.0](/fr-CA/docs/authenticate/protocols/oauth) prend en charge plusieurs flux (ou types d’octroi). Les <Tooltip tip="Flow : processus pouvant être étendus à l’aide d’Actions. Chaque Flow est composé d’un ou de plusieurs Triggers et représente le pipeline logique par lequel l’information circule à un moment précis du parcours Auth0." cta="Voir le glossaire" href="/fr-CA/docs/glossary?term=Flow">Flow</Tooltip> sont des moyens d’obtenir un <Tooltip tip="Flow : processus pouvant être étendus à l’aide d’Actions. Chaque Flow est composé d’un ou de plusieurs Triggers et représente le pipeline logique par lequel l’information circule à un moment précis du parcours Auth0." cta="Voir le glossaire" href="/fr-CA/docs/glossary?term=Access+Token">jeton d’accès</Tooltip>. Le choix du flux adapté à votre cas d’utilisation dépend surtout de votre [type d’application](/fr-CA/docs/get-started/applications), mais d’autres paramètres entrent aussi en ligne de compte, comme le niveau de confiance accordé au client ou l’expérience que vous souhaitez offrir à vos utilisateurs.

<div id="oauth-20-terminology">
  ## Terminologie d’OAuth 2.0
</div>

* **<Tooltip tip="Propriétaire de la ressource : entité (comme 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>** : Entité qui peut accorder l’accès à une ressource protégée. Il s’agit généralement de l’utilisateur final.
* **Client** : Application qui demande l’accès à une ressource protégée au nom du propriétaire de la ressource.
* **<Tooltip tip="Serveur de ressources : serveur hébergeant des ressources protégées. Les serveurs de ressources acceptent les demandes de ressources protégées et y répondent." cta="Voir le glossaire" href="/fr-CA/docs/glossary?term=Resource+Server">Serveur de ressources</Tooltip>** : Serveur qui héberge les ressources protégées. C’est l’API à laquelle vous voulez accéder.
* **<Tooltip tip="Serveur d’autorisation : serveur centralisé qui aide à 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 offertes à un utilisateur." cta="Voir le glossaire" href="/fr-CA/docs/glossary?term=Authorization+Server">Serveur d’autorisation</Tooltip>** : 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.
* **Agent utilisateur** : Agent utilisé par le propriétaire de la ressource pour interagir avec le client (par exemple, un navigateur ou une application native).

<div id="is-the-client-the-resource-owner">
  ## Le client est-il le propriétaire de la ressource ?
</div>

Le premier point à trancher consiste à déterminer si l’entité qui doit accéder aux ressources est une machine. Dans le cas d’une autorisation entre machines, le client est aussi le propriétaire de la ressource; aucune autorisation de l’utilisateur final n’est donc nécessaire. Par exemple, une tâche cron peut utiliser une API pour importer des données dans une base de données. Dans cet exemple, la tâche cron est le client et le propriétaire de la ressource puisqu’elle détient le <Tooltip tip="ID client : valeur d’identification attribuée à votre ressource enregistrée par Auth0." cta="Voir le glossaire" href="/fr-CA/docs/glossary?term=Client+ID">ID client</Tooltip> et le <Tooltip tip="Secret client : secret utilisé par un client (application) pour s’authentifier auprès du serveur d’autorisation; il ne devrait être connu que du client et du serveur d’autorisation et doit être suffisamment aléatoire pour ne pas pouvoir être deviné." cta="Voir le glossaire" href="/fr-CA/docs/glossary?term=Client+Secret">secret client</Tooltip> et les utilise pour obtenir un jeton d’accès auprès du serveur d’autorisation.

Si cette situation correspond à vos besoins, consultez [Client Credentials Flow](/fr-CA/docs/get-started/authentication-and-authorization-flow/client-credentials-flow) pour comprendre son fonctionnement et voir comment l’implémenter.

<div id="is-the-client-a-web-app-executing-on-the-server">
  ## Le client est-il une application Web exécutée sur un serveur ?
</div>

Si le client est une application Web classique exécutée sur un serveur, le flux de code d’autorisation est celui à privilégier. Grâce à ce flux, le client peut récupérer un jeton d’accès et, au besoin, un <Tooltip tip="jeton d’actualisation : jeton utilisé pour obtenir un nouvel 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 considéré comme l’option la plus sûre, puisque le jeton d’accès est transmis directement au serveur Web qui héberge le client, sans passer par le navigateur Web de l’utilisateur, ce qui réduit les risques d’exposition.

Si cette situation correspond à vos besoins, consultez [flux de code d’autorisation](/fr-CA/docs/get-started/authentication-and-authorization-flow/authorization-code-flow) pour comprendre le fonctionnement de ce flux et voir comment l’implémenter.

<div id="is-the-client-absolutely-trusted-with-user-credentials">
  ## Le client est-il absolument digne de confiance en ce qui concerne les identifiants de l’utilisateur?
</div>

Ce point de décision peut mener à l’octroi « Resource Owner Password Credentials Grant ». Dans ce flux, on demande à l’utilisateur final de saisir ses identifiants (identifiant/mot de passe), généralement à l’aide d’un formulaire interactif. Ces renseignements sont envoyés au serveur principal, puis à Auth0. Il est donc impératif que le client soit absolument digne de confiance pour recevoir ces renseignements.

Cet octroi ne devrait être utilisé que lorsque les flux avec redirection (comme le [flux de code d’autorisation](/fr-CA/docs/get-started/authentication-and-authorization-flow/authorization-code-flow)) sont impossibles. Si c’est votre cas, consultez [Resource Owner Password Flow](/fr-CA/docs/get-started/authentication-and-authorization-flow/resource-owner-password-flow) pour savoir comment ce flux fonctionne et comment l’implémenter.

<div id="is-the-client-a-single-page-app">
  ## Le client est-il une application monopage ?
</div>

Si le client est une application monopage (SPA), c’est-à-dire une application qui s’exécute dans un navigateur à l’aide d’un langage de script comme JavaScript, deux options d’octroi sont possibles : le flux de code d’autorisation avec Proof Key for Code Exchange (PKCE) et le flux implicite avec Form Post. Dans la plupart des cas, nous recommandons d’utiliser le flux de code d’autorisation avec PKCE, puisque le jeton d’accès n’est pas exposé côté client, et ce flux peut renvoyer des [jetons d’actualisation](/fr-CA/docs/secure/tokens/refresh-tokens).

Pour en savoir plus sur le fonctionnement de ce flux et sur la façon de l’implémenter, consultez [Authorization Code Flow with Proof Key for Code Exchange (PKCE)](/fr-CA/docs/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce). Le [SDK Auth0 Single-Page App](/fr-CA/docs/libraries/auth0-single-page-app-sdk) fournit une API de haut niveau pour implémenter le flux de code d’autorisation avec PKCE dans les SPA.

Si votre SPA n’a pas besoin d’un jeton d’accès, vous pouvez utiliser le flux implicite avec Form Post. Pour en savoir plus sur le fonctionnement de ce flux et sur la façon de l’implémenter, consultez [Implicit Flow with Form Post](/fr-CA/docs/get-started/authentication-and-authorization-flow/implicit-flow-with-form-post).

<div id="is-the-client-a-nativemobile-app">
  ## Le client est-il une application native/mobile ?
</div>

Si l’application est native, utilisez le **flux de code d’autorisation avec Proof Key for Code Exchange (PKCE)**.

Pour en savoir plus sur le fonctionnement de ce flux et sa mise en œuvre, consultez [Flux de code d’autorisation avec Proof Key for Code Exchange (PKCE)](/fr-CA/docs/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce).

<div id="i-have-an-application-that-needs-to-talk-to-different-resource-servers">
  ## J’ai une application qui doit communiquer avec différents serveurs de ressources
</div>

Si une même application a besoin de jetons d’accès pour différents serveurs de ressources, il faut effectuer plusieurs appels à `/authorize` (c’est-à-dire exécuter plusieurs fois le même <Tooltip tip="Flux d’autorisation : autorisation accordée (ou processus) défini dans le cadre OAuth 2.0." cta="Voir le glossaire" href="/fr-CA/docs/glossary?term=Authorization+Flow">flux d’autorisation</Tooltip> ou différents flux d’autorisation). Chaque autorisation utilisera une valeur différente pour `audience`, ce qui produira un jeton d’accès différent à la fin du flux. Pour en savoir plus, consultez la [spécification OAuth 2.0: Audience Information](https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00#section-3).

<div id="can-i-try-the-endpoints-before-i-implement-my-application">
  ## Puis-je essayer les points de terminaison avant d’implémenter mon application ?
</div>

Bien sûr ! Vous pouvez utiliser notre [extension Authentication API Debugger](/fr-CA/docs/customize/extensions/authentication-api-debugger-extension). Vous trouverez des instructions détaillées pour chaque point de terminaison `/grant` dans notre [documentation de référence de l’API d’authentification](https://auth0.com/docs/api/authentication).

* Pour le point de terminaison Authorize, allez à [Authorize Application](https://auth0.com/docs/api/authentication#authorize-application) et lisez le paragraphe « Test this endpoint » pour le type d’autorisation que vous voulez tester.
* Pour le <Tooltip tip="Point de terminaison de jeton : point de terminaison sur le serveur d’autorisation utilisé pour demander des jetons par programmation." cta="Voir le glossaire" href="/fr-CA/docs/glossary?term=Token+endpoint">point de terminaison de jeton</Tooltip>, allez à [Get Token](https://auth0.com/docs/api/authentication#get-token) et lisez la section « Test this endpoint » pour le type d’autorisation que vous voulez tester.

<div id="does-the-client-application-need-to-challenge-users-for-authentication-without-browser-interaction">
  ## L’application cliente doit-elle demander aux utilisateurs de s’authentifier sans interaction avec le navigateur ?
</div>

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  L’authentification backchannel initiée par le client est actuellement en accès anticipé. Pour activer CIBA, communiquez avec votre gestionnaire de compte technique.
</Callout>

L’authentification backchannel initiée par le client (CIBA) est une norme de l’<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> Foundation qui permet de mettre en œuvre un flux d’authentification alternatif à [OpenID Connect](https://openid.net/developers/how-connect-works/). CIBA se distingue du flux OpenID Connect habituel de la façon suivante :

* l’application cliente lance le processus d’authentification au nom de l’utilisateur final.
* aucun navigateur n’est nécessaire pour l’interaction avec l’utilisateur.
* la communication se fait directement entre l’application cliente et le fournisseur OpenID.

CIBA est utile lorsque l’utilisateur ne fait pas confiance à l’application cliente, que l’application cliente n’a pas de navigateur ou que l’utilisateur ne se trouve pas devant l’application qui exige l’authentification. Voici quelques exemples d’utilisation des flux CIBA :

* **Arrivée de l’utilisateur à une borne de vente au détail :** dans les scénarios de ramassage en magasin, un utilisateur peut s’authentifier à une borne publique et confirmer sa présence.
* **Authentification dans un centre d’appels ou au comptoir d’un agent :** un agent de centre d’appels peut lancer un flux d’authentification pour authentifier un appelant, généralement à l’aide d’une application mobile personnalisée sur un téléphone intelligent.
* **Authentification sur un appareil sans dispositif d’entrée :** par exemple, un haut-parleur intelligent (ou un autre appareil connecté) peut utiliser un service d’arrière-plan pour communiquer avec l’utilisateur aux fins d’authentification, généralement à l’aide d’une application mobile personnalisée sur un téléphone intelligent.

CIBA définit deux appareils :

* **Appareil d’accès au service** : l’appareil qui permet à l’utilisateur d’utiliser un service.
* **Appareil d’authentification** : l’appareil sur lequel l’utilisateur s’authentifiera et accordera son consentement.

Pour en savoir plus, consultez [Flux d’authentification backchannel initiée par le client](/fr-CA/docs/get-started/authentication-and-authorization-flow/client-initiated-backchannel-authentication-flow).