> ## 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 approprié pour votre type d’application, des applications Web côté serveur et des SPA aux flux machine à machine et d’appareil.

# Quel flux OAuth 2.0 devrais-je utiliser ?

Le [cadre d’autorisation OAuth 2.0](/docs/fr-ca/authenticate/protocols/oauth) prend en charge plusieurs flux (ou grants) différents. Les <Tooltip tip="Flux : processus qui peuvent être étendus à l’aide d’Actions. Chaque flux est composé d’un ou de plusieurs déclencheurs et représente le pipeline logique par lequel l’information circule à une étape donnée du parcours Auth0." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=Flow">flux</Tooltip> permettent d’obtenir un <Tooltip tip="Flux : processus qui peuvent être étendus à l’aide d’Actions. Chaque flux est composé d’un ou de plusieurs déclencheurs et représente le pipeline logique par lequel l’information circule à une étape donnée du parcours Auth0." cta="Voir le glossaire" href="/docs/fr-ca/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](/docs/fr-ca/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 OAuth 2.0
</div>

* **<Tooltip tip="Resource Owner : entité (comme 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>**: Entité capable d’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="Resource Server : serveur hébergeant des ressources protégées. Les serveurs de ressources acceptent les requêtes visant des ressources protégées et y répondent." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=Resource+Server">Serveur de ressources</Tooltip>**: Serveur qui héberge les ressources protégées. Il s’agit de l’API à laquelle vous voulez accéder.
* **<Tooltip tip="Authorization Server : 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 auxquelles un utilisateur a accès." cta="Voir le glossaire" href="/docs/fr-ca/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 appropriée. 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 de décision consiste à déterminer si l’entité qui doit accéder aux ressources est une machine. Dans le cas d’une autorisation machine-to-machine, le Client est aussi le propriétaire de la ressource, donc aucune autorisation de l’utilisateur final n’est nécessaire. Par exemple, un cron job peut utiliser une API pour importer des renseignements dans une base de données. Dans cet exemple, le cron job est le Client et le propriétaire de la ressource, puisqu’il détient le <Tooltip tip="Client ID : valeur d’identification attribuée à votre ressource enregistrée par Auth0." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=Client+ID">Client ID</Tooltip> et le <Tooltip tip="Client Secret : Secret utilisé par un client (application) pour s’authentifier auprès du serveur d’autorisation; il ne doit ê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="/docs/fr-ca/glossary?term=Client+Secret">Client Secret</Tooltip> et les utilise pour obtenir un jeton d’accès auprès du serveur d’autorisation.

Si ce cas correspond à vos besoins, consultez [Client Credentials Flow](/docs/fr-ca/get-started/authentication-and-authorization-flow/client-credentials-flow) pour comprendre le fonctionnement de ce flux et savoir comment le mettre en œuvre.

<div id="is-the-client-a-web-app-executing-on-the-server">
  ## Le Client est-il une application web qui s’exécute sur le serveur ?
</div>

Si le Client est une application web traditionnelle qui s’exécute sur un serveur, le Flux de code d’autorisation est celui que vous devriez utiliser. Grâce à lui, 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 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 considéré comme le choix le plus sûr, puisque le jeton d’accès est transmis directement au serveur web qui héberge le Client, sans passer par le navigateur de l’utilisateur ni risquer d’être exposé.

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

<div id="is-the-client-absolutely-trusted-with-user-credentials">
  ## Peut-on faire absolument confiance au client avec les identifiants de l’utilisateur?
</div>

Ce point de décision peut mener à l’octroi par mot de passe du propriétaire de la ressource. Dans ce flux, on demande à l’utilisateur final de saisir ses identifiants (identifiant/mot de passe), généralement au moyen d’un formulaire interactif. Ces renseignements sont envoyés au backend, puis transmis à Auth0. Il est donc impératif que le client soit absolument digne de confiance pour traiter ces renseignements.

Cet octroi ne devrait être utilisé que lorsque les flux avec redirection (comme le [flux de code d’autorisation](/docs/fr-ca/get-started/authentication-and-authorization-flow/authorization-code-flow)) ne sont pas possibles. Si c’est votre cas, consultez [le flux par mot de passe du propriétaire de la ressource](/docs/fr-ca/get-started/authentication-and-authorization-flow/resource-owner-password-flow) pour comprendre son fonctionnement et la façon de 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 de `grant` s’offrent à vous : le flux de code d’autorisation avec 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, car le jeton d’accès n’est pas exposé côté client et ce flux peut renvoyer des [jetons d’actualisation](/docs/fr-ca/secure/tokens/refresh-tokens).

Pour en savoir plus sur le fonctionnement de ce flux et sur la façon de l’implémenter, consultez [Flux de code d’autorisation avec clé de preuve pour l’échange de code (PKCE)](/docs/fr-ca/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce). Le [Auth0 Single-Page App SDK](/docs/fr-ca/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 [Flux implicite avec Form Post](/docs/fr-ca/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 une application native, utilisez le **flux de code d’autorisation avec clé de preuve pour l’échange de code (PKCE)**.

Pour en savoir plus sur le fonctionnement de ce flux et sur sa mise en œuvre, consultez [flux de code d’autorisation avec clé de preuve pour l’échange de code (PKCE)](/docs/fr-ca/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, plusieurs requêtes vers `/authorize` (c’est-à-dire plusieurs exécutions du même <Tooltip tip="Flux d’autorisation : grant d’autorisation (ou flux de travail) spécifié dans le framework OAuth 2.0." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=Authorization+Flow">flux d’autorisation</Tooltip> ou d’un autre) sont nécessaires. Chaque autorisation utilisera une valeur différente pour `audience`, ce qui se traduira par un jeton d’accès différent à la fin du flux. Pour en savoir plus, consultez la spécification [OAuth 2.0: Audience Information Specification](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 tester les endpoints avant d’implémenter mon application?
</div>

Bien sûr! Vous pouvez utiliser notre [extension Authentication API Debugger](/docs/fr-ca/customize/extensions/authentication-api-debugger-extension). Vous trouverez des instructions détaillées pour chaque endpoint `/grant` dans notre [Authentication API Reference](https://auth0.com/docs/api/authentication).

* Pour l’endpoint Authorize, consultez [Authorize Application](https://auth0.com/docs/api/authentication#authorize-application) et lisez le paragraphe « Test this endpoint » pour le grant que vous souhaitez tester.
* Pour le <Tooltip tip="Token endpoint : endpoint sur le serveur d’autorisation utilisé pour demander des jetons par programmation." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=Token+endpoint">Token endpoint</Tooltip>, consultez [obtenir un jeton](https://auth0.com/docs/api/authentication#get-token) et lisez la section « Test this endpoint » pour le grant que vous souhaitez 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 passer par un navigateur?
</div>

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  Client-Initiated Backchannel Authentication est actuellement en accès anticipé. Pour activer CIBA, communiquez avec votre chargé de compte technique.
</Callout>

Client-Initiated Backchannel Authentication (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 leurs renseignements de connexion." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=OpenID">OpenID</Tooltip> Foundation qui permet de mettre en œuvre un flux d’authentification différent de [OpenID Connect](https://openid.net/developers/how-connect-works/). CIBA diffère du flux OpenID Connect standard en ce que :

* L’application cliente lance le processus d’authentification au nom de l’utilisateur final.
* Il n’est pas nécessaire d’utiliser un navigateur pour interagir avec l’utilisateur.
* Il existe une communication directe entre l’application cliente et le fournisseur OpenID.

CIBA est utile lorsque l’utilisateur ne peut pas se fier à l’application cliente, que l’application cliente n’a pas de navigateur ou que l’utilisateur n’est pas devant l’application qui exige l’authentification. Voici quelques exemples où les flux CIBA peuvent être utilisés :

* **Arrivée de l’utilisateur à une borne de vente en magasin :** dans un scénario de ramassage en magasin, l’utilisateur peut s’authentifier à une borne publique et confirmer sa présence.
* **Authentification dans un centre d’appels ou au comptoir d’un préposé :** un agent de centre d’appels peut lancer un flux d’authentification pour authentifier un appelant, généralement au moyen 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 backend pour joindre l’utilisateur afin de l’authentifier, généralement au moyen d’une application mobile personnalisée sur un téléphone intelligent.

CIBA définit deux appareils :

* **appareil de consommation** : l’appareil qui permet à l’utilisateur de consommer un service.
* **appareil d’authentification** : l’appareil sur lequel l’utilisateur s’authentifiera et accordera son consentement.

Pour en savoir plus, consultez [Client-Initiated Backchannel Authentication Flow](/docs/fr-ca/get-started/authentication-and-authorization-flow/client-initiated-backchannel-authentication-flow).