Saltar al contenido principal
Dado que el flujo de contraseña del propietario del recurso (ROP) implica que la aplicación gestione la contraseña del usuario, no debe utilizarse con clientes de terceros.
Aunque no lo recomendamos, las aplicaciones altamente confiables pueden usar el flujo de contraseña de (definido en OAuth 2.0 RFC 6749, sección 4.3 y a veces llamado Resource Owner Password Grant o ROPG), en el que se solicita a los usuarios que proporcionen sus credenciales (username/correo electrónico/teléfono y contraseña), normalmente mediante un formulario interactivo. Como las credenciales se envían al backend y pueden almacenarse para usarse más adelante antes de intercambiarse por un , es imprescindible que la aplicación sea completamente confiable para manejar esta información. Incluso si se cumple esta condición, el flujo de contraseña del propietario del recurso solo debe utilizarse cuando no sea posible usar flujos basados en redirección (como el flujo de código de autorización).

​
Cómo funciona

Diagrama: flujo de contraseña del propietario del recurso
  1. El usuario hace clic en Iniciar sesión en la aplicación e introduce sus credenciales.
  2. Su aplicación reenvía las credenciales del usuario a su Servidor de autorización de Auth0 (endpoint /oauth/token).
  3. Su Servidor de autorización de Auth0 valida las credenciales.
  4. Su Servidor de autorización de Auth0 responde con un Token de acceso (y, opcionalmente, un Token de actualización).
  5. Su aplicación puede usar el Token de acceso para llamar a una API y acceder a información sobre el usuario.
  6. La API responde con los datos solicitados.

​
Cómo implementarlo

La forma más sencilla de implementar el flujo de contraseña del propietario del recurso es seguir nuestro tutorial para usar los endpoints de nuestra API y llamar a tu API mediante el flujo de contraseña del propietario del recurso.

​
Compatibilidad con realms

Auth0 proporciona un grant de extensión que ofrece una funcionalidad similar al grant Resource Owner Password, pero le permite mantener directorios de usuarios independientes (que se asignan a conexiones independientes) y especificar cuál usar durante el flujo. Por ejemplo, supongamos que quiere mostrar un menú desplegable en la interfaz de usuario de inicio de sesión de su aplicación para que los usuarios puedan elegir su tipo de usuario: Employees o Customers. En este caso, configuraría Employees y Customers como realms (y configuraría una conexión correspondiente para cada uno), lo que permite mantener las credenciales de empleados y clientes en directorios de usuarios independientes. Cuando solicite un token, enviará el valor del realm junto con las credenciales del usuario, y el realm enviado se utilizará para verificar la contraseña. Para obtener más información sobre cómo implementar este grant de extensión, consulte Call Your API Using Resource Owner Password Flow: Configure Realm Support.

​
Rules

Rules se ejecutan en el flujo de contraseña del propietario del recurso (incluido el grant de extensión Realm). Sin embargo, las reglas de redirección no funcionan. Si intenta realizar una redirección especificando context.redirect en su Rule, el flujo de autenticación devolverá un error. Para obtener más información sobre Rules, lea Auth0 Rules. Para obtener más información sobre las reglas de redirección, lea Redirigir usuarios desde Rules.

​
Soporte para MFA

Si necesita usar el flujo de contraseña del propietario del recurso, pero requiere una autenticación más robusta, puede agregar (MFA). Para obtener más información, lea Autenticarse mediante el flujo de contraseña del propietario del recurso con MFA.

​
Protección contra ataques

Al usar el flujo de contraseña del propietario del recurso con , es posible que algunas funciones de no funcionen correctamente. Sin embargo, se pueden evitar algunos problemas comunes. Para obtener más información, consulte Evitar problemas comunes con flujo de contraseña del propietario del recurso y la protección contra ataques.

​
Más información