Skip to main content
Auth0 utilise le protocole OpenID Connect (OIDC) et le cadre d’autorisation OAuth 2.0 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/ ni d’autres aspects techniques de l’authentification et de l’autorisation. 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 ?.
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.
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.

​
Flux de code d’autorisation

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 avec clé de preuve pour l’échange de code (PKCE)

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 une protection renforcée de la confidentialité

Pendant le processus d’authentification et d’autorisation, certains cas d’utilisation, comme l’autorisation transactionnelle, é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 implicite avec Form Post

Comme solution de rechange au flux de code d’autorisation, OAuth 2.0 offre le flux implicite, qui est destiné aux , ou aux applications qui ne peuvent pas stocker des de manière sécurisée. Bien que cette approche ne soit plus considérée comme une bonne pratique pour demander des , 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 pour effectuer l’authentification de l’utilisateur.

​
Flux hybride

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 . 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.

​
Client Credentials Flow

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).

​
Flux d’autorisation de l’appareil

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’ de l’appareil (défini dans OAuth 2.0). À utiliser avec les applications mobiles/natives.

​
Flux de mot de passe du propriétaire de la ressource

Bien que nous ne le recommandions pas, les applications hautement fiables peuvent utiliser le flux de mot de passe du , 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).

​
Client-Initiated Backchannel Authentication Flow

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.

​
Échange de jetons personnalisé

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. 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. En associant un Profil d’échange de jetons personnalisé à 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.