Flux d’authentification et d’autorisation
Auth0 utilise le protocole OpenID Connect (OIDC) et Cadre d’applications Authorization OAuth 2.0 pour authentifier les utilisateurs et obtenir leur autorisation pour accéder aux ressources protégées. Avec Auth0, vous pouvez facilement prendre en charge différents flux dans vos propres applications et API sans vous soucier des spécifications OIDC/OAuth 2.0 ou 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 appareils.
Si vous ne savez pas quel flux utiliser, nous pouvons vous aider à prendre une décision. Pour en savoir plus, veuillez consulter Quel flux OAuth 2.0 dois-je utiliser?.
Pendant l’exécution de plusieurs flux, votre application doit aussi être authentifiée auprès du serveur d’autorisations. Pour en savoir plus sur l’authentification des applications, lisez Authentifiants d’application.
Flux de code d’autorisation
Étant donné que 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 échange un code d’autorisation contre un jeton.
Flux de code d’autorisation avec Proof Key for Code Exchange (PKCE)
Lors de 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 monopages présentent des défis particuliers. Pour atténuer ces problèmes, OAuth 2.0 fournit une version du flux de code d’autorisation qui utilise une Proof Key for Code Exchange (PKCE).
Flux de code d’autorisation avec Proof Key for Code Exchange (PKCE)
Ajouter une connexion à l’aide du flux de code d’autorisation avec PKCE
Appeler l’API à l’aide du flux de code d’autorisation avec PKCE
Flux de code d’autorisation avec protection améliorée de la confidentialité
Au cours du processus d’authentification et d’autorisation, certains cas d’utilisation tels que transactional authorization (autorisation transactionnelle) échangent des informations contextuelles, qui peuvent contenir des données sensibles. Pour protéger les données et les informations sensibles, vous pouvez utiliser différentes améliorations de protocole pour le flux du code d’autorisation :
Flux de code d’autorisation avec demandes d’autorisation riches (RAR)
Flux de code d’autorisation avec demandes d’autorisation poussées (PAR)
Flux de code d’autorisation avec demandes d’autorisation sécurisées par JWT (JAR)
Flux implicite avec Form Post
Comme alternative au flux de code d’autorisation, OAuth 2.0 fournit le flux implicite, destiné aux clients publics ou aux applications qui ne sont pas en mesure de stocker en toute sécurité les secrets client. Bien que cela ne soit plus considéré comme une bonne pratique pour demander des jetons d’accès, lorsqu’il est utilisé avec le mode de réponse Form Post, il offre un flux de travail rationalisé si l’application n’a besoin que d’un jeton d’ID pour effectuer l’authentification de l’utilisateur.
Flux hybride
Les applications capables de stocker en toute sécurité les secrets client peuvent bénéficier de l’utilisation du flux hybride, qui combine les fonctionnalités du flux de code d’autorisation et du flux implicite avec Form Post pour permettre à votre application d’avoir un accès immédiat à un jeton d’identification tout en garantissant la récupération sécurisée et sûre des jetons d'accès et d'actualisation. Cela peut s’avérer utile lorsque votre application doit accéder immédiatement à des informations sur l’utilisateur, mais doit effectuer un traitement avant d’accéder à des ressources protégées pendant une période prolongée.
Flux des identifiants client
Avec les applications de communication entre machines (M2M), telles que 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. Pour ce scénario, les méthodes d’authentification traditionnelles (comme le nom d’utilisateur et le mot de passe, ou encore la connexion via un réseau social) n’ont aucun sens. Au lieu de cela, les applications M2M utilisent le Flux des identifiants client (défini dans OAuth 2.0 RFC 6749, section 4.4).
Flux d’autorisation d’appareil
Au lieu d’authentifier directement les utilisateurs, les appareils à saisie limitée qui se connectent à l’internet demandent aux utilisateurs d’aller cliquer sur un lien sur leur ordinateur ou leur téléphone intelligent et d’y autoriser l’appareil. Cela permet d’améliorer l’expérience utilisateur pour les appareils qui ne disposent pas d’un moyen facile de saisir du texte. Pour ce faire, les applications d’appareil utilisent le flux d’autorisation d’appareil (rédigé dans OAuth 2.0). À utiliser avec des applications mobiles/natives.
Flux de mot de passe du propriétaire de ressource
Bien que nous ne le recommandions pas, les applications hautement fiables peuvent utiliser le flux de mot de passe du propriétaire de ressource, qui demande aux utilisateurs de fournir des informations d’identification (identifiant et mot de passe), généralement à l’aide d’un formulaire interactif. Le flux de mot de passe du propriétaire de 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 par canal d’appui initié par le client
L’authentification CIBA est actuellement en accès anticipé. Pour activer l’authentification CIBA, communiquez avec votre Gestionnaire de compte technique.
Avec le flux d’authentification par canal d’appui initié par le client (CIBA), plutôt que d’authentifier directement l’utilisateur, le système dorsal de l’application cliente lance un flux d’authentification pour demander à l’utilisateur de s’authentifier. L’authentification elle-même est effectuée sur un périphérique d’authentification distinct, généralement un téléphone intelligent exécutant une application personnalisée.