Llame a su API mediante el flujo de contraseña del propietario del recurso

Aprenda a llamar a su propia API desde aplicaciones de alta confianza mediante el flujo de contraseña del propietario del recurso.

Este tutorial te ayudará a llamar a tu propia API mediante el flujo de contraseña del propietario del recurso. Si quieres obtener más información sobre cómo funciona el flujo y por qué deberías usarlo, consulta flujo de contraseña del propietario del recurso.

Debido a 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 en clientes de terceros.

Auth0 facilita la implementación en tu aplicación del flujo de contraseña del propietario del recurso (a veces llamado concesión de contraseña del propietario del recurso o ROPG) mediante la Authentication API. Sigue leyendo para aprender a llamar a nuestra API directamente.

​

Requisitos previos

Antes de comenzar este tutorial:

• Registre su aplicación en Auth0.

  • Seleccione un Tipo de aplicación de Aplicaciones web regulares.
  • Agregue una URL de devolución de llamada permitida de {https://yourApp/callback}. Este campo no puede dejarse sin definir o se devolverá un mensaje de error.
  • Asegúrese de que los Tipos de concesión de su aplicación incluyan Password. Para saber cómo hacerlo, lea Actualizar tipos de concesión.
  • Si desea que su aplicación pueda usar tokens de actualización, asegúrese de que los Tipos de concesión de la aplicación incluyan Token de actualización. Para saber cómo hacerlo, lea Actualizar tipos de concesión. Para obtener más información sobre los tokens de actualización, lea Tokens de actualización.

• Registre su API en Auth0

  • Si desea que su API reciba tokens de actualización para poder obtener tokens nuevos cuando caduquen los anteriores, habilite Permitir acceso sin conexión.

• Configure una conexión

  • Asegúrese de que su conexión pueda autenticar usuarios con nombre de usuario y contraseña (por ejemplo, conexiones de base de datos, o AD/LDAP, ADFS o Azure Active Directory conexiones empresariales).

• Actualice o deshabilite cualquier regla, de modo que solo afecten a conexiones específicas. Si obtiene un error access_denied al probar el Password Owner Resource Grant, esto podría deberse a una regla de control de acceso.

​

Pasos

1. Configurar el inquilino:Establece la conexión predeterminada del inquilino.
2. Solicitar tokens: Intercambia tu código de autorización por tokens.
3. Llamar a la API: Usa el Token de acceso obtenido para llamar a tu API.
4. Tokens de actualización: Usa un Token de actualización para solicitar nuevos tokens cuando caduquen los actuales.

Opcional: Explorar ejemplos de casos de uso

Opcional: Configurar compatibilidad con realm

Opcional: Configurar MFA

Opcional: Configurar protección contra ataques

​

Configurar el inquilino

El flujo de contraseña del propietario del recurso requiere una conexión capaz de autenticar usuarios mediante username y contraseña, por lo que debe configurar la conexión predeterminada del inquilino.

1. Vaya a Auth0 Dashboard > Tenant Settings y desplácese hacia abajo hasta encontrar la configuración Default Directory.
2. Introduzca el nombre de la conexión que desea usar. Asegúrese de que pueda autenticar usuarios mediante username y contraseña.

​

Solicitar tokens

Para llamar a tu API, primero debes obtener las credenciales del usuario, normalmente mediante un formulario interactivo. Una vez que tu aplicación tenga las credenciales, debes canjearlas por tokens. Para ello, debes hacer una solicitud POST a la URL del token.

​

Ejemplo de solicitud POST a la URL del token

Parámetros

Nombre del parámetro	Descripción
grant_type	Establezca este valor en password.
username	El username introducido por el usuario.
password	La contraseña introducida por el usuario.
client_id	El ID de cliente de su aplicación. Puede encontrar este valor en la configuración de la aplicación.
client_assertion	Un JWT que contiene una aserción firmada con las credenciales de su aplicación. Es obligatorio cuando Private Key JWT es el método de autenticación de su aplicación.
client_assertion_type	El valor es urn:ietf:params:oauth:client-assertion-type:jwt-bearer. Es obligatorio cuando Private Key JWT es el método de autenticación de la aplicación.
client_secret	El Secreto del cliente de su aplicación. Es obligatorio cuando Client Secret es el método de autenticación de la aplicación y la configuración de la aplicación es Post o Basic. Si su aplicación no es de alta confianza (por ejemplo, una SPA), no establezca este parámetro.
audience	La audiencia del token, es decir, su API. Puede encontrarla en el campo Identificador de la pestaña de configuración de su API.
scope	Especifica los alcances para los que desea solicitar autorización, que determinan qué claims (o atributos de usuario) desea que se devuelvan. Deben estar separados por espacios. Puede solicitar cualquiera de los alcances estándar de OpenID Connect (OIDC) relacionados con el usuario, como profile o email, claims personalizados que sigan un formato con espacio de nombres, o cualquier alcance compatible con la API de destino (por ejemplo, read:contacts). Incluya offline_access para obtener un Token de actualización (asegúrese de que el campo Allow Offline Access esté habilitado en la configuración de la aplicación).

​

Respuesta

Si todo va bien, recibirás una respuesta HTTP 200 con una carga útil que incluye los valores access_token, refresh_token, id_token, token_type y expires_in:

{
  "access_token": "eyJz93a...k4laUWw",
  "refresh_token": "GEbRxBN...edjnXbL",
  "id_token": "eyJ0XAi...4faeEoQ",
  "token_type": "Bearer",
  "expires_in": 36000
}

Valide sus tokens antes de guardarlos. Para saber cómo hacerlo, lea Validar ID Tokens y Validar Tokens de acceso.

Los tokens de actualización deben almacenarse de forma segura, ya que permiten que un usuario permanezca autenticado prácticamente indefinidamente.

Flujo de contraseña del propietario del recurso y alcances estándar

Debido a que proporcionar una contraseña otorga acceso total, cualquier intercambio basado en contraseña da acceso a todos los alcances. Por ejemplo, si no incluye alcances de API en la solicitud, todos los alcances de la API se incluirán en el Token de acceso. Del mismo modo, si incluye solo el scope openid en la solicitud, se devolverán todos los alcances estándar de OpenID Connect relacionados con openid. En estos casos, el parámetro scope se incluirá en la respuesta y enumerará los alcances emitidos.

Obtener información de usuario sin un ID Token

Si necesita información del usuario, incluya el scope openid en su solicitud. Si la API usa RS256 como algoritmo de firma, el Token de acceso incluirá /userinfo como una audiencia válida, lo que significa que puede usarlo para llamar al endpoint /userinfo y recuperar los claims del usuario.

​

Llamar a la API

Para llamar a su API, la aplicación debe enviar el Token de acceso obtenido como Bearer Token en el encabezado Authorization de la solicitud HTTP.

​

Tokens de actualización

Ya recibiste un token de actualización si has seguido este tutorial y completaste lo siguiente:

• configuraste tu API para permitir el acceso sin conexión
• incluiste el scope offline_access cuando iniciaste la solicitud de autenticación mediante el endpoint de autorización.

Puedes usar el Token de actualización para obtener un nuevo token de acceso. Normalmente, un usuario solo necesitará un nuevo token de acceso cuando el anterior expire o cuando obtenga acceso a un recurso nuevo por primera vez. No es una buena práctica llamar al endpoint para obtener un nuevo token de acceso cada vez que llamas a una API, y Auth0 aplica límites de frecuencia que restringen la cantidad de solicitudes al endpoint que pueden ejecutarse con el mismo token desde la misma IP.

Para renovar tu token, realiza una solicitud POST al endpoint /oauth/token de la Authentication API con grant_type=refresh_token.

​

Ejemplo de POST a la URL del token

Parámetros

Nombre del parámetro	Descripción
grant_type	Establécelo en refresh_token.
client_id	El ID de cliente de tu aplicación. Puedes encontrar este valor en la configuración de la aplicación.
refresh_token	El token de actualización que se debe usar.
scope	(opcional) Una lista de alcances solicitados separada por espacios. Si no se envía, se usarán los alcances originales; de lo contrario, puedes solicitar un conjunto reducido de alcances. Ten en cuenta que debe estar codificada para URL.

​

Respuesta

Si todo sale bien, recibirás una respuesta HTTP 200 con una carga útil que incluye un nuevo access_token, su duración en segundos (expires_in), los valores de scope concedidos y token_type.

{
  "access_token": "eyJ...MoQ",
  "expires_in": 86400,
  "scope": "openid offline_access",
  "token_type": "Bearer"
}

Valida tus tokens antes de guardarlos. Para saber cómo hacerlo, consulta Validar ID Tokens y Validar tokens de acceso.

​

Ejemplos de casos de uso

​

Personalizar tokens

Puede usar Actions para cambiar los alcances devueltos de los tokens de acceso y/o agregar claims a los tokens de acceso y a los ID Tokens. (Para obtener más información sobre Actions, lea Auth0 Actions.) Para ello, agregue la siguiente Action, que se ejecutará después de que el usuario se autentique:

exports.onExecutePostLogin = async (event, api) => {
  // Agregar claims personalizados al token de acceso y al ID Token
  api.accessToken.setCustomClaim('https://foo/bar', 'value');
  api.idToken.setCustomClaim('https://fiz/baz', 'some other value');

  // Modificar el scope del token de acceso
  api.accessToken.addScope('foo');
  api.accessToken.addScope('bar');
};

Los alcances estarán disponibles en el token después de que se ejecute la Action.

Auth0 devuelve la información de perfil en un formato estructurado de claims, tal como se define en la especificación de OpenID Connect (OIDC). Esto significa que los claims personalizados agregados a los ID tokens o los tokens de acceso deben ajustarse a las directrices y restricciones para evitar posibles colisiones.

​

Configurar la 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 separados (que se asignan a conexiones independientes) y especificar cuál usar durante el flujo.

Para usar esta variante, debe:

• Establecer el parámetro de solicitud grant_type en http://auth0.com/oauth/grant-type/password-realm.
• Enviar un parámetro de solicitud adicional llamado realm y establecerlo con el nombre del realm al que pertenece el usuario. Por ejemplo, si ha configurado una conexión de base de datos para empleados internos llamada employees y el usuario pertenece a ella, establezca realm en employees.

Conexiones como realms

Cualquier conexión que admita autenticación activa puede configurarse como un realm, incluidas las conexiones de base de datos, las conexiones sin contraseña y las conexiones empresariales de AD/LDAP, ADFS y Azure Active Directory.

​

Configurar MFA

Si necesita usar el flujo de contraseña del propietario del recurso, pero requiere una autenticación más robusta, puede agregar autenticación multifactor (MFA). Para saber cómo hacerlo, consulte Autenticar con el flujo de contraseña del propietario del recurso con MFA.

​

Configurar la protección contra ataques

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

​

Más información

• Framework de autorización de OAuth 2.0
• Protocolo OpenID Connect
• Tokens