Saltar al contenido principal
El uso de para llamar a endpoints de está quedando obsoleto. Debe usar . El período de gracia para esta migración comenzó el 31 de marzo de 2018. Después de completar la migración a tokens de acceso, desactive el interruptor Permitir ID Token para la autenticación de Management API v2 en el Dashboard. Si usa ID Token para llamar a cualquiera de los siguientes endpoints, esta migración le afecta. Estos endpoints ahora pueden aceptar tokens de acceso normales. No cambia nada más en el funcionamiento de los endpoints. Puede esperar los mismos esquemas de solicitud y respuesta, y solo tendrá que actualizar el token que usa para la autorización.

​
Endpoints afectados

EndpointCaso de uso
GET /api/v2/users/Obtener la información de un usuario
GET /api/v2/users//enrollmentsObtener todas las inscripciones en MFA de Guardian de un usuario
PATCH /api/v2/users/Actualizar la información de un usuario
DELETE /api/v2/users//multifactor/Eliminar la configuración del proveedor de MFA de un usuario
POST /api/v2/device-credentialsCrear una clave pública para un dispositivo
DELETE /api/v2/device-credentials/Eliminar una credencial de dispositivo
POST/api/v2/users//identitiesVincular cuentas de usuario de varios Proveedores de identidad
DELETE /api/v2/users//identities//Desvincular cuentas de usuario

​
Actions

​
Cambios en los alcances

Las acciones que puede realizar con la Management API dependen de los alcances que contenga su token de acceso. Con esta migración, puede obtener un token de acceso limitado que solo puede actualizar los datos del usuario que ha iniciado sesión, o un token de acceso que puede actualizar los datos de cualquier usuario. En la siguiente matriz, puede ver qué alcances debe tener su token en cada caso y para cada endpoint. Por ejemplo, si obtiene un token de acceso que contiene el scope read:users, puede recuperar los datos de cualquier usuario mediante el endpoint GET /api/v2/users/{id}. Sin embargo, si su token contiene el scope read:current_user, solo puede recuperar la información del usuario que ha iniciado sesión en ese momento (aquel para el que se emitió el token).
EndpointScope para el usuario actualScope para cualquier usuario
GET /api/v2/users/read:current_userread:users
GET /api/v2/users//enrollmentsread:current_userread:users
POST/api/v2/users//identitiesupdate:current_user_identitiesupdate:users
DELETE /api/v2/users//identities//update:current_user_identitiesupdate:users
PATCH /api/v2/users/update:current_user_metadataupdate:users
PATCH /api/v2/users/create:current_user_metadataupdate:users
DELETE /api/v2/users//multifactor/delete:current_user_metadataupdate:users
POST /api/v2/device-credentialscreate:current_user_device_credentialscreate:device_credentials
DELETE /api/v2/device-credentials/delete:current_user_device_credentialsdelete:device_credentials

​
Obtener tokens de acceso

Auth0 ha cambiado la forma en que obtiene un token para los endpoints mencionados anteriormente. Existen varias formas de autenticar a un usuario y obtener tokens, según la tecnología y el que utilice para autenticar:
  • SPA que se ejecuta en un navegador: Use el endpoint de autorización.
  • Aplicación web que se ejecuta en un servidor, una aplicación móvil, un proceso de servidor o una aplicación de alta confianza: Use el .
  • Autenticación cruzada: Use Lock integrado o auth0.js para autenticar a los usuarios cuando las solicitudes provengan de dominios distintos.

​
endpoint de autorización

En esta sección, usaremos un ejemplo para mostrar las diferencias en cómo se obtiene un token con el endpoint de autorización. Ten en cuenta que, independientemente del endpoint que quieras migrar, los cambios son los mismos; lo único que varía son los alcances que especificas en la solicitud. En el ejemplo siguiente, usas el endpoint GET User by ID para recuperar la información completa del perfil del usuario que inició sesión. Para ello, primero autenticaremos al usuario mediante el grant implícito y recuperaremos el token o los tokens. A continuación, puedes ver una implementación del enfoque anterior, que obtiene un token de ID y luego lo usa para llamar al endpoint. En el ejemplo siguiente, puede ver el nuevo método para obtener un token de acceso. Para obtener un token de acceso con el que puedas acceder a la Management API:
  • Establece audience en https://{yourDomain}/api/v2/
  • Solicita el scope ${scope}
  • Establece response_type en id_token token para que Auth0 envíe tanto un token de ID como un token de acceso
Si decodificas el token de acceso recibido y revisas su contenido, verás lo siguiente: Observa que aud está configurado con el URI de la API de tu inquilino, scope está configurado como ${scope} y sub está configurado con el ID del usuario que inició sesión. Una vez que tengas el token de acceso, puedes usarlo para llamar al endpoint. Esta parte sigue siendo la misma; no cambia nada más en la solicitud, excepto el valor que usas como token Bearer. La respuesta también sigue siendo la misma.

​
endpoint de token

En esta sección, usaremos un ejemplo para mostrar las diferencias en cómo obtener un token con el endpoint de token. Sin embargo, tenga en cuenta que, independientemente del endpoint que quiera migrar, los cambios son los mismos; lo único que varía son los alcances que especifique en la solicitud. En el ejemplo siguiente, quiere usar el endpoint GET User by ID para recuperar toda la información del perfil del usuario que inició sesión. Primero, autentique al usuario mediante el grant Password Exchange y luego recupere los tokens. A continuación, puede ver una implementación del enfoque anterior, que obtiene un token de ID (y luego lo usa para llamar al endpoint). En el siguiente ejemplo, también puede ver el nuevo enfoque para obtener un token de acceso. Para obtener un Token de acceso que pueda acceder a la Management API:
  • Configura aud como https://{yourDomain}/api/v2/
  • Solicita el scope read:current_user
Una vez que tengas el token de acceso, puedes usarlo para llamar al endpoint. Esta parte sigue siendo la misma; no cambia nada más en la solicitud, excepto el valor que uses como token Bearer. La respuesta también sigue siendo la misma.

​
Lock o auth0.js integrados

Si integra Lock o auth0.js v9 en su aplicación, está usando autenticación entre orígenes. Esto se utiliza para autenticar a los usuarios cuando las solicitudes provienen de dominios diferentes. Si usa auth0.js para acceder a la Management API y administrar sus usuarios, tendrá que actualizar su script. En el ejemplo siguiente, puede ver el método anterior. En este ejemplo, puede ver el nuevo método.
  • Solicita tanto un token de ID como un token de acceso en la respuesta responseType: 'token id_token'
  • Establece la Management API como la de destino del token audience: 'https://YOUR_DOMAIN/api/v2/'
  • Solicita el permiso necesario scope: 'read:current_user'
  • Autentícate en la Management API con el token de acceso

​
Cambios en vinculación de cuentas

Los cambios en esta funcionalidad son los siguientes:
  • Ya no se puede usar un token de ID en el encabezado Authorization
  • Si usas un token de acceso en el encabezado Authorization, con update:users como permiso concedido, puedes enviar en el cuerpo de la solicitud el user_id o el token de ID de la cuenta secundaria
  • Si usas un token de acceso en el encabezado Authorization, con update:current_user_metadata como permiso concedido, solo puedes enviar el token de ID de la cuenta secundaria en el cuerpo de la solicitud. Debe cumplirse lo siguiente:
    • El token de ID debe estar firmado con RS256 (puedes establecer este valor en Dashboard > Applications > configuración de la aplicación > Advanced Settings > OAuth)
    • El claim aud del token de ID debe identificar la aplicación y tener el mismo valor que el claim azp del token de acceso”

​
Restricciones

Los tokens de acceso que se usan para acceder a la Management API solo deben tener un valor en el claim aud. Si el token contiene más de un valor, la solicitud a la Management API generará un error.

​
Más información