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

​
Flux de code d’autorisation

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 avec Proof Key for Code Exchange (PKCE)

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 et 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 les données et les 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 propose le flux implicite, qui est destiné aux , ou aux applications qui ne peuvent pas stocker des de façon sécurisée. Bien qu’il ne soit plus considéré comme une bonne pratique pour demander des , 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 pour authentifier 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’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 . 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 d’identification du client

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’autorisation des appareils

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

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

Même si nous ne le recommandons pas, les applications hautement dignes de confiance peuvent utiliser le , 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) ne peuvent pas être utilisés.

​
Flux d’authentification sur canal secondaire initié par l’application

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.

​
Custom Token Exchange

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. 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. En associant un profil de 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.