> ## 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 les différents flux utilisés pour l’authentification et l’autorisation des applications et des API.

# Flux d’authentification et d’autorisation

Auth0 utilise le [protocole OpenID Connect (OIDC)](/fr-CA/docs/authenticate/protocols/openid-connect-protocol) et le [cadre d’autorisation OAuth 2.0](/fr-CA/docs/authenticate/protocols/oauth) pour authentifier les utilisateurs et obtenir leur autorisation d’accéder à des ressources protégées. Avec Auth0, vous pouvez facilement prendre en charge différents flux dans vos propres applications et API sans avoir à vous soucier des spécifications d’OIDC/<Tooltip tip="OAuth 2.0 : cadre d’autorisation qui définit les protocoles et les flux de travail d’autorisation." cta="Voir le glossaire" href="/fr-CA/docs/glossary?term=OAuth+2.0">OAuth 2.0</Tooltip> ni d’autres aspects techniques de [l’authentification et de l’autorisation](/fr-CA/docs/get-started/identity-fundamentals/authentication-and-authorization).

Nous prenons en charge des scénarios pour les applications côté serveur, mobiles, de bureau, côté client, machine à machine et pour appareils.

Si vous ne savez pas quel flux utiliser, nous pouvons vous aider à choisir. Pour en savoir plus, consultez [Quel flux OAuth 2.0 dois-je utiliser ?](/fr-CA/docs/get-started/authentication-and-authorization-flow/which-oauth-2-0-flow-should-i-use).

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  Dans le cadre de plusieurs flux, votre application doit aussi s’authentifier auprès du serveur d’autorisation. Pour en savoir plus sur l’authentification des applications, consultez [Identifiants d’application](/fr-CA/docs/secure/application-credentials).
</Callout>

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  Selon les politiques d’accès des applications à l’API que vous configurez pour une API, vous devrez peut-être créer les autorisations d’application correspondantes pour votre application. Pour en savoir plus, consultez [Accès des applications aux API : politiques et autorisations d’application](/fr-CA/docs/get-started/applications/application-access-to-apis-client-grants).
</Callout>

<div id="authorization-code-flow">
  ## Flux de code d’autorisation
</div>

Comme les applications Web classiques sont des applications côté serveur dont le code source n’est pas exposé publiquement, elles peuvent utiliser le flux de code d’autorisation, qui permet d’échanger un code d’autorisation contre un jeton.

* [Flux de code d’autorisation](/fr-CA/docs/get-started/authentication-and-authorization-flow/authorization-code-flow)
* [Ajouter la connexion à l’aide du flux de code d’autorisation](/fr-CA/docs/get-started/authentication-and-authorization-flow/authorization-code-flow/add-login-auth-code-flow)
* [Appeler une API à l’aide du flux de code d’autorisation](/fr-CA/docs/get-started/authentication-and-authorization-flow/authorization-code-flow/call-your-api-using-the-authorization-code-flow)

<div id="authorization-code-flow-with-proof-key-for-code-exchange-pkce">
  ## Flux de code d’autorisation avec Proof Key for Code Exchange (PKCE)
</div>

Pendant l’authentification, les applications mobiles et natives peuvent utiliser le flux de code d’autorisation, mais elles nécessitent une sécurité supplémentaire. De plus, les applications monopage présentent des défis particuliers. Pour y remédier, OAuth 2.0 propose une version du flux de code d’autorisation qui utilise Proof Key for Code Exchange (PKCE).

* [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)
* [Ajouter Login à l’aide du flux de code d’autorisation avec PKCE](/fr-CA/docs/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce/add-login-using-the-authorization-code-flow-with-pkce)
* [Appeler une API à l’aide du flux de code d’autorisation avec PKCE](/fr-CA/docs/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce/call-your-api-using-the-authorization-code-flow-with-pkce)

<div id="authorization-code-flow-with-enhanced-privacy-protection">
  ## Flux de code d’autorisation et protection renforcée de la confidentialité
</div>

Pendant le processus d’authentification et d’autorisation, certains cas d’utilisation, comme l’[autorisation transactionnelle](/fr-CA/docs/secure/highly-regulated-identity/transactional-authorization-with-authorization-code-flow), échangent des informations contextuelles qui peuvent contenir des données sensibles. Pour protéger les données et les renseignements sensibles, vous pouvez utiliser différentes améliorations du protocole pour le flux de code d’autorisation :

* [Flux de code d’autorisation et Rich Authorization Requests (RAR)](/fr-CA/docs/get-started/authentication-and-authorization-flow/authorization-code-flow/authorization-code-flow-with-rar)
* [Flux de code d’autorisation et Pushed Authorization Requests (PAR)](/fr-CA/docs/get-started/authentication-and-authorization-flow/authorization-code-flow/authorization-code-flow-with-par)
* [Flux de code d’autorisation et JWT-Secured Authorization Requests (JAR)](/fr-CA/docs/get-started/authentication-and-authorization-flow/authorization-code-flow/authorization-code-flow-with-jar)
* [JSON Web Encryption (JWE)](/fr-CA/docs/secure/tokens/access-tokens/json-web-encryption)

<div id="implicit-flow-with-form-post">
  ## Flux implicite avec Form Post
</div>

Comme solution de rechange au flux de code d’autorisation, OAuth 2.0 propose le flux implicite, qui est destiné aux <Tooltip tip="Application publique : application qui ne peut pas conserver des identifiants de façon sécurisée. Par exemple, une application native de bureau ou mobile, ainsi qu’une application Web côté client basée sur JavaScript (comme une application monopage (SPA))." cta="Voir le glossaire" href="/fr-CA/docs/glossary?term=Public+Clients">applications publiques</Tooltip>, ou aux applications qui ne peuvent pas stocker des <Tooltip tip="Application publique : application qui ne peut pas conserver des identifiants de façon sécurisée. Par exemple, une application native de bureau ou mobile, ainsi qu’une application Web côté client basée sur JavaScript (comme une application monopage (SPA))." cta="Voir le glossaire" href="/fr-CA/docs/glossary?term=Client+Secrets">secrets client</Tooltip> de façon sécurisée. Bien qu’il ne soit plus considéré comme une bonne pratique pour demander des <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="/fr-CA/docs/glossary?term=Access+Tokens">jetons d’accès</Tooltip>, lorsqu’il est utilisé avec le mode de réponse Form Post, il offre tout de même un flux de travail simplifié si l’application a seulement besoin d’un <Tooltip tip="ID token : identifiant destiné à l’application 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> pour authentifier l’utilisateur.

* [Flux implicite avec Form Post](/fr-CA/docs/get-started/authentication-and-authorization-flow/implicit-flow-with-form-post)
* [Ajouter Login à l’aide du flux implicite avec Form Post](/fr-CA/docs/get-started/authentication-and-authorization-flow/implicit-flow-with-form-post/add-login-using-the-implicit-flow-with-form-post)
* [Authentifier les SPA avec des cookies](/fr-CA/docs/manage-users/cookies/spa-authenticate-with-cookies)

<div id="hybrid-flow">
  ## Flux hybride
</div>

Les applications qui peuvent stocker des Secrets client de façon sécuritaire peuvent tirer parti du flux hybride, qui combine des fonctionnalités du flux de code d’autorisation et du flux implicite avec Form Post pour permettre à votre application d’accéder immédiatement à un jeton d’identité, tout en assurant la récupération sûre et sécurisée des jetons d’accès et des <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+tokens">jetons d’actualisation</Tooltip>. Cela peut être utile lorsque votre application doit accéder immédiatement à des renseignements sur l’utilisateur, mais doit effectuer un certain traitement avant d’obtenir l’accès à des ressources protégées pour une période prolongée.

* [Flux hybride](/fr-CA/docs/get-started/authentication-and-authorization-flow/hybrid-flow)
* [Appeler une API à l’aide du flux hybride](/fr-CA/docs/get-started/authentication-and-authorization-flow/hybrid-flow/call-api-hybrid-flow)

<div id="client-credentials-flow">
  ## Flux d’identification du client
</div>

Avec les applications machine à machine (M2M), comme les CLI, les démons ou les services qui s’exécutent sur votre back-end, le système authentifie et autorise l’application plutôt qu’un utilisateur. Dans ce scénario, les mécanismes d’authentification habituels, comme identifiant et mot de passe ou les connexions avec les réseaux sociaux, n’ont pas de sens. Les applications M2M utilisent plutôt le flux d’identification du client (défini dans la RFC 6749 d’OAuth 2.0, section 4.4).

* [Flux d’identification du client](/fr-CA/docs/get-started/authentication-and-authorization-flow/client-credentials-flow)
* [Appeler une API à l’aide du flux d’identification du client](/fr-CA/docs/get-started/authentication-and-authorization-flow/client-credentials-flow/call-your-api-using-the-client-credentials-flow)

<div id="device-authorization-flow">
  ## Flux d’autorisation des appareils
</div>

Pour les appareils connectés à Internet dont les capacités de saisie sont limitées, au lieu d’authentifier directement l’utilisateur, l’appareil lui demande d’ouvrir un lien sur son ordinateur ou son téléphone intelligent afin d’autoriser l’appareil. Cela évite une expérience utilisateur médiocre sur les appareils qui ne permettent pas de saisir facilement du texte. Pour ce faire, les applications pour appareils utilisent le <Tooltip tip="Flux d’autorisation : autorisation accordée (ou flux de travail) spécifiée dans le cadre OAuth 2.0." cta="Voir le glossaire" href="/fr-CA/docs/glossary?term=Authorization+Flow">flux d’autorisation</Tooltip> des appareils (défini dans OAuth 2.0). À utiliser avec les applications mobiles/natives.

* [Flux d’autorisation des appareils](/fr-CA/docs/get-started/authentication-and-authorization-flow/device-authorization-flow)
* [Appeler une API à l’aide du flux d’autorisation des appareils](/fr-CA/docs/get-started/authentication-and-authorization-flow/device-authorization-flow/call-your-api-using-the-device-authorization-flow)

<div id="resource-owner-password-flow">
  ## Flux de mot de passe du propriétaire de la ressource
</div>

Même si nous ne le recommandons pas, les applications hautement dignes de confiance peuvent utiliser le <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">flux de mot de passe du propriétaire de la ressource</Tooltip>, qui demande aux utilisateurs de fournir leurs identifiants de connexion (identifiant et mot de passe), généralement au moyen d’un formulaire interactif. Le flux de mot de passe du propriétaire de la ressource ne doit être utilisé que lorsque les flux basés sur la redirection (comme le [flux de code d’autorisation](/fr-CA/docs/get-started/authentication-and-authorization-flow/authorization-code-flow)) ne peuvent pas être utilisés.

* [Flux de mot de passe du propriétaire de la ressource](/fr-CA/docs/get-started/authentication-and-authorization-flow/resource-owner-password-flow)
* [Appeler une API à l’aide du flux de mot de passe du propriétaire de la ressource](/fr-CA/docs/get-started/authentication-and-authorization-flow/resource-owner-password-flow/call-your-api-using-resource-owner-password-flow)

<div id="client-initiated-backchannel-authentication-flow">
  ## Flux d’authentification sur canal secondaire initié par l’application
</div>

Avec le flux d’authentification sur canal secondaire initié par l’application (CIBA), plutôt que d’authentifier directement l’utilisateur, le backend de l’application lance un flux d’authentification pour inviter l’utilisateur à s’authentifier. L’authentification elle-même se fait sur un appareil distinct, généralement un téléphone intelligent exécutant une application personnalisée.

* [Flux d’authentification sur canal secondaire initié par l’application](/fr-CA/docs/get-started/authentication-and-authorization-flow/client-initiated-backchannel-authentication-flow)
* [Authentification de l’utilisateur avec CIBA](/fr-CA/docs/get-started/authentication-and-authorization-flow/client-initiated-backchannel-authentication-flow/user-authentication-with-ciba)
* [Autorisation de l’utilisateur avec CIBA](/fr-CA/docs/get-started/authentication-and-authorization-flow/client-initiated-backchannel-authentication-flow/user-authorization-with-ciba)

<div id="custom-token-exchange">
  ## Custom Token Exchange
</div>

Custom Token Exchange (CTE) permet aux applications d’échanger des jetons d’identité existants contre des jetons Auth0 en appelant le point de terminaison `/oauth/token`, comme le définit la [RFC 8693](https://datatracker.ietf.org/doc/html/rfc8693). Par exemple, vous pouvez utiliser Custom Token Exchange pour échanger des jetons Auth0 afin d’accéder à une autre audience au nom de l’utilisateur. Pour en savoir plus sur les cas d’utilisation de Custom Token Exchange, consultez [Exemples de cas d’utilisation](/fr-CA/docs/authenticate/custom-token-exchange/cte-example-use-cases).

En associant un [profil de Custom Token Exchange](/fr-CA/docs/authenticate/custom-token-exchange/configure-custom-token-exchange) à une Action contenant une logique personnalisée, vous pouvez mettre en œuvre des flux d’identité hautement personnalisés en échangeant un jeton de sécurité contre un autre, tout en gardant le contrôle sur la logique d’autorisation.