Skip to main content
Comme le flux Resource Owner Password (ROP) implique que l’application traite le mot de passe de l’utilisateur, il ne doit pas être utilisé par des clients tiers.
Même si nous ne le recommandons pas, les applications hautement fiables peuvent utiliser le flux Password (défini dans OAuth 2.0 RFC 6749, section 4.3 et parfois appelé Resource Owner Password Grant ou ROPG), dans lequel les utilisateurs doivent fournir leurs identifiants (username/email/phone et mot de passe), généralement au moyen d’un formulaire interactif. Comme ces identifiants sont envoyés au backend et peuvent être stockées pour une utilisation ultérieure avant d’être échangées contre un , il est impératif que l’application soit jugée entièrement digne de confiance pour traiter ces renseignements. Même si cette condition est remplie, le flux Resource Owner Password ne devrait être utilisé que lorsque les flux avec redirection (comme le flux de code d’autorisation) ne peuvent pas être utilisés.

​
Fonctionnement

Diagramme - Flux Resource Owner Password
  1. L’utilisateur clique sur Login dans l’application et saisit ses identifiants.
  2. Votre application transmet les identifiants de l’utilisateur à votre Auth0 Authorization Server (point de terminaison /oauth/token).
  3. Votre Auth0 Authorization Server valide les identifiants.
  4. Votre Auth0 Authorization Server renvoie un jeton d’accès (et, au besoin, un Refresh Token).
  5. Votre application peut utiliser le jeton d’accès pour envoyer une requête à une API afin d’accéder à des renseignements sur l’utilisateur.
  6. L’API renvoie les données demandées.

​
Comment le mettre en œuvre

La façon la plus simple de le mettre en œuvre consiste à suivre notre tutoriel pour utiliser nos points de terminaison d’API afin d’appeler votre API à l’aide du flux Resource Owner Password.

​
Prise en charge des realms

Auth0 fournit un grant d’extension offrant une fonctionnalité semblable à celle du grant Resource Owner Password, mais qui vous permet de conserver des répertoires d’utilisateurs distincts (correspondant à des connexions distinctes) et de préciser lequel utiliser pendant le processus. Par exemple, supposons que vous vouliez afficher une liste déroulante dans l’interface de connexion de votre application afin de permettre aux utilisateurs de choisir leur type d’utilisateur : Employees ou Customers. Dans ce cas, vous configureriez Employees et Customers comme des realms (et mettriez en place une connexion correspondante pour chacun), ce qui permet de conserver les identifiants des employés et des clients dans des répertoires d’utilisateurs distincts. Lorsque vous demandez un token, vous soumettez la valeur du realm avec les identifiants de l’utilisateur, et le realm soumis sera utilisé pour vérifier le mot de passe. Pour en savoir plus sur la mise en œuvre de ce grant d’extension, consultez Call Your API Using flux Resource Owner Password: Configure Realm Support.

​
Rules

Les Rules s’exécutent dans le cadre du flux Resource Owner Password (y compris le grant d’extension Realm). Toutefois, les redirect rules ne fonctionnent pas. Si vous tentez d’effectuer une redirection en définissant context.redirect dans votre règle, le flux d’authentification renverra une erreur. Pour en savoir plus sur les Rules, consultez Auth0 Rules. Pour en savoir plus sur les redirect rules, consultez Redirect Users from Within Rules.

​
Soutien pour la MFA

Si vous devez utiliser le flux Resource Owner Password, mais que vous avez besoin d’une authentification plus robuste, vous pouvez ajouter l’ (MFA). Pour savoir comment faire, consultez S’authentifier à l’aide du flux Resource Owner Password avec la MFA.

​
Protection contre les attaques

Lors de l’utilisation du flux Resource Owner Password avec , certaines fonctionnalités de peuvent ne pas fonctionner. Il est toutefois possible d’éviter certains problèmes courants. Pour en savoir plus, consultez Éviter les problèmes courants avec le flux Resource Owner Password et la protection contre les attaques.

​
En savoir plus