Migra tu flujo de contraseña del propietario del recurso

Describe cómo migrar las llamadas y respuestas de la API de contraseña de /oauth/ro a /oauth/token.

Se añadió compatibilidad con la contraseña de propietario del recurso en /oauth/token. El uso del endpoint /oauth/ro quedó obsoleto el 08 de julio de 2017. Anteriormente, el endpoint /oauth/ro se usaba para intercambiar un código de un solo uso (OTP) recibido por el usuario final por correo electrónico o SMS por un token de ID y un token de acceso. Auth0 ha implementado una nueva API que reemplaza a /oauth/ro para este caso de uso y te recomendamos migrar al nuevo endpoint.

​

Características afectadas

Este cambio te afecta si usas el flujo de contraseña del propietario del recurso (a veces llamado Resource Owner Password Grant o ROPG) y llamas a /oauth/ro directamente sin usar bibliotecas ni SDKs de Auth0. Las bibliotecas de Auth0, como Lock o Auth0.js, se han actualizado para dejar de usar /oauth/ro internamente. Si usas la biblioteca lock-sin contraseña, ahora puedes usar el modo sin contraseña en Lock.

Cuando vence el token de acceso basado en /oauth/ro de un usuario, Auth0 lo obliga a volver a autenticarse (es necesario forzar el cierre de sesión), ya que el Token de actualización de /oauth/ro no puede usarse para llamar a /oauth/token y obtener un nuevo token de acceso. Todos los usuarios que tengan una sesión iniciada actualmente deberán volver a iniciar sesión durante una migración de /oauth/ro a /oauth/token.

​

Actions

​

Cambios en las solicitudes

Anteriormente, la carga útil de una solicitud a /oauth/ro era similar a esta:

{
  "grant_type": "password",
  "client_id": "123",
  "username": "alice",
  "password": "A3ddj3w", 
  "connection": "my-database-connection",
  "scope": "openid email favorite_color offline_access",
  "device": "my-device-name"
}

La nueva implementación incluye los siguientes cambios:

• El endpoint para realizar el intercambio de tokens ahora es /oauth/token.
• El grant type propio de Auth0 se usa para autenticar usuarios de una conexión (o realm) específica.
• Auth0 admite los alcances estándar de OIDC, junto con los alcances que haya definido en su API personalizada.
• Un scope que no encaje en una de estas categorías, como favorite_color, ya no es un scope válido.
• Se elimina el parámetro device.
• El parámetro audience es opcional.

A continuación se muestra un ejemplo de la carga útil de una solicitud a /oauth/token:

{
  "grant_type": "http://auth0.com/oauth/grant-type/password-realm",
  "client_id": "123",
  "username": "alice",
  "password": "A3ddj3w",
  "realm": "my-database-connection",
  "scope": "openid email offline_access",
  "audience": "https://api.example.com"
}

• Aquí, el grant type se especifica como password-realm, en lugar del password estándar.
• Los parámetros client_id, username y password no cambian.
• Se incluye realm porque estamos usando el grant type Password Realm y sustituye al parámetro connection de las llamadas anteriores.
• El parámetro scope es básicamente el mismo, pero no admite valores que no sean OIDC.
• Se puede agregar el parámetro audience, que indica la API audiencia a la que estará destinado el token.

​

Cambios en las respuestas

Las respuestas de /oauth/ro tenían un formato similar a este:

{
  "access_token": "SlAV32hkKG",
  "token_type": "Bearer",
  "refresh_token": "8xLOxBtZp8",
  "expires_in": 3600,
  "id_token": "eyJ..."
}

• El token de acceso devuelto es válido para llamar al endpoint /userinfo (siempre que la API especificada por el parámetro audience use RS256 como algoritmo de firma) y, opcionalmente, a la API personalizada, si se especificó una.
• El token de ID se firmará obligatoriamente con RS256 si lo solicita un cliente público.
• Se devolverá un Token de actualización solo si se concedió el scope offline_access y la API tiene activada la opción Permitir acceso sin conexión.

A continuación, se muestra un ejemplo de la respuesta conforme con OIDC de /oauth/token:

{
  "access_token": "eyJ...",
  "token_type": "Bearer",
  "refresh_token": "8xLOxBtZp8",
  "expires_in": 3600,
  "id_token": "eyJ..."
}

​

Verificar la migración

1. Una vez que hayas migrado tu base de código y estés seguro de que tus aplicaciones no están haciendo llamadas al endpoint, ve a Dashboard > Configuración del Tenant > Avanzado.
2. Desplázate hasta Endpoint /oauth/ro legado en Migraciones y desactívalo. Al desactivar este interruptor, se deshabilita el endpoint obsoleto para tu inquilino, lo que impide que se siga usando.

Si al desactivar este interruptor se producen fallos de inicio de sesión, es señal de que todavía no has eliminado por completo todo el código legado de tus aplicaciones.

Una vez completadas correctamente las migraciones en los entornos de producción, el interruptor puede desactivarse y dejarse así para garantizar que las funciones obsoletas ya no puedan usarse.