> ## 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)](/docs/fr-ca/authenticate/protocols/openid-connect-protocol) et le [cadre d’autorisation OAuth 2.0](/docs/fr-ca/authenticate/protocols/oauth) pour authentifier les utilisateurs et obtenir leur autorisation pour 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 OIDC/<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+2.0">OAuth 2.0</Tooltip> ni d’autres aspects techniques de l’[authentification et de l’autorisation](/docs/fr-ca/get-started/identity-fundamentals/authentication-and-authorization).

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

Si vous ne savez pas quel flux utiliser, nous pouvons vous aider à choisir. Pour en savoir plus, lisez [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).

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

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  Selon les politiques d’accès des applications aux API que vous configurez pour une API, vous devrez peut-être créer les autorisations client correspondantes pour votre application. Pour en savoir plus, lisez [Accès des applications aux API : politiques et autorisations client](/docs/fr-ca/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 traditionnelles 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 échange un code d’autorisation contre un jeton.

* [Flux de code d’autorisation](/docs/fr-ca/get-started/authentication-and-authorization-flow/authorization-code-flow)
* [Ajouter la connexion à l’aide du flux de code d’autorisation](/docs/fr-ca/get-started/authentication-and-authorization-flow/authorization-code-flow/add-login-auth-code-flow)
* [Appeler l’API à l’aide du flux de code d’autorisation](/docs/fr-ca/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 clé de preuve pour l’échange de code (PKCE)
</div>

Pendant l’authentification, les applications mobiles et les applications natives peuvent utiliser le flux de code d’autorisation, mais elles ont besoin d’une sécurité supplémentaire. De plus, les applications monopage posent des défis particuliers. Pour atténuer ces défis, OAuth 2.0 propose une version du flux de code d’autorisation qui utilise une clé de preuve pour l’échange de code (PKCE).

* [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)
* [Ajouter l’ouverture de session à l’aide du flux de code d’autorisation avec PKCE](/docs/fr-ca/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](/docs/fr-ca/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 avec une protection renforcée de la confidentialité
</div>

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

* [Flux de code d’autorisation avec des Rich Authorization Requests (RAR)](/docs/fr-ca/get-started/authentication-and-authorization-flow/authorization-code-flow/authorization-code-flow-with-rar)
* [Flux de code d’autorisation avec des requêtes d’autorisation poussées (PAR)](/docs/fr-ca/get-started/authentication-and-authorization-flow/authorization-code-flow/authorization-code-flow-with-par)
* [Flux de code d’autorisation avec des JWT-Secured Authorization Requests (JAR)](/docs/fr-ca/get-started/authentication-and-authorization-flow/authorization-code-flow/authorization-code-flow-with-jar)
* [JSON Web Encryption (JWE)](/docs/fr-ca/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 offre le flux implicite, qui est destiné aux <Tooltip tip="Client public : client (application) qui ne peut pas conserver des identifiants de façon sécurisée. Les exemples incluent une application native de bureau ou mobile et une application Web côté client basée sur JavaScript (comme une SPA)." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=Public+Clients">clients publics</Tooltip>, ou aux applications qui ne peuvent pas stocker des <Tooltip tip="Client public : client (application) qui ne peut pas conserver des identifiants de façon sécurisée. Les exemples incluent une application native de bureau ou mobile et une application Web côté client basée sur JavaScript (comme une SPA)." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=Client+Secrets">secrets client</Tooltip> de manière sécurisée. Bien que cette approche ne soit plus considérée comme une bonne pratique pour demander des <Tooltip tip="Jeton d’accès : information d’autorisation d’accès, sous la forme d’une chaîne opaque ou d’un JWT, utilisée pour accéder à une API." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=Access+Tokens">jetons d’accès</Tooltip>, lorsqu’elle est utilisée avec le mode de réponse Form Post, elle offre un processus simplifié si l’application a seulement besoin d’un <Tooltip tip="Jeton d’ID : information d’identification destinée 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">jeton ID</Tooltip> pour effectuer l’authentification de l’utilisateur.

* [Flux implicite avec Form Post](/docs/fr-ca/get-started/authentication-and-authorization-flow/implicit-flow-with-form-post)
* [Ajouter la connexion à l’aide du flux implicite avec Form Post](/docs/fr-ca/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](/docs/fr-ca/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’obtenir immédiatement un jeton ID, tout en assurant une récupération sécuritaire et fiable des jetons d’accès et des <Tooltip tip="Refresh Token: Jeton utilisé pour obtenir un jeton d’accès renouvelé sans obliger les utilisateurs à se connecter de nouveau." cta="Voir le glossaire" href="/docs/fr-ca/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 qu’elle doit effectuer un certain traitement avant d’accéder à des ressources protégées pendant une période prolongée.

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

<div id="client-credentials-flow">
  ## Client Credentials Flow
</div>

Avec les applications machine-to-machine (M2M), comme les CLI, les démons ou les services exécutés sur votre back-end, le système authentifie et autorise l’application plutôt qu’un utilisateur. Dans ce contexte, les mécanismes d’authentification habituels, comme Identifier + Password ou les connexions via les réseaux sociaux, ne s’appliquent pas. Les applications M2M utilisent plutôt le Client Credentials Flow (défini dans la RFC 6749 d’OAuth 2.0, section 4.4).

* [Client Credentials Flow](/docs/fr-ca/get-started/authentication-and-authorization-flow/client-credentials-flow)
* [Appeler l’API à l’aide du Client Credentials Flow](/docs/fr-ca/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 de l’appareil
</div>

Avec les appareils à capacité de saisie limitée qui se connectent à Internet, 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 mauvaise expérience utilisateur sur les appareils qui ne permettent pas de saisir du texte facilement. Pour ce faire, les applications de l’appareil utilisent le flux d’<Tooltip tip="Flux d’autorisation : mécanisme d’autorisation (ou workflow) défini dans le framework OAuth 2.0." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=Authorization+Flow">autorisation</Tooltip> de l’appareil (défini dans OAuth 2.0). À utiliser avec les applications mobiles/natives.

* [Flux d’autorisation de l’appareil](/docs/fr-ca/get-started/authentication-and-authorization-flow/device-authorization-flow)
* [Appeler une API à l’aide du flux d’autorisation de l’appareil](/docs/fr-ca/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>

Bien que nous ne le recommandions pas, les applications hautement fiables peuvent utiliser le flux de mot de passe du <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="/docs/fr-ca/glossary?term=Resource+Owner">propriétaire de la ressource</Tooltip>, dans lequel les utilisateurs doivent fournir leurs identifiants (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 lorsqu’il est impossible d’utiliser des flux avec redirection (comme le [flux de code d’autorisation](/docs/fr-ca/get-started/authentication-and-authorization-flow/authorization-code-flow)).

* [Flux de mot de passe du propriétaire de la ressource](/docs/fr-ca/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](/docs/fr-ca/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">
  ## Client-Initiated Backchannel Authentication Flow
</div>

Avec le Client-Initiated Backchannel Authentication Flow (CIBA), au lieu d’authentifier directement l’utilisateur, le backend de l’application cliente déclenche un flux d’authentification pour inviter l’utilisateur à s’authentifier. L’authentification elle-même s’effectue sur un appareil d’authentification distinct, généralement un téléphone intelligent exécutant une application personnalisée.

* [Client-Initiated Backchannel Authentication Flow](/docs/fr-ca/get-started/authentication-and-authorization-flow/client-initiated-backchannel-authentication-flow)
* [Authentification de l’utilisateur avec CIBA](/docs/fr-ca/get-started/authentication-and-authorization-flow/client-initiated-backchannel-authentication-flow/user-authentication-with-ciba)
* [Autorisation de l’utilisateur avec CIBA](/docs/fr-ca/get-started/authentication-and-authorization-flow/client-initiated-backchannel-authentication-flow/user-authorization-with-ciba)

<div id="custom-token-exchange">
  ## Échange de jetons personnalisé
</div>

L’Échange de jetons personnalisé (CTE) permet aux applications d’échanger des jetons d’identité préexistants contre des jetons Auth0 en appelant le endpoint `/oauth/token`, comme défini dans la [RFC 8693](https://datatracker.ietf.org/doc/html/rfc8693). Par exemple, vous pouvez utiliser l’Échange de jetons personnalisé 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 l’Échange de jetons personnalisé, consultez [Exemples de cas d’utilisation](/docs/fr-ca/authenticate/custom-token-exchange/cte-example-use-cases).

En associant un [Profil d’échange de jetons personnalisé](/docs/fr-ca/authenticate/custom-token-exchange/configure-custom-token-exchange) à une Action qui contient une logique personnalisée, vous pouvez mettre en place des flux de travail liés à l’identité hautement personnalisés en échangeant un jeton de sécurité contre un autre, tout en gardant la maîtrise de la logique d’autorisation.