Saltar al contenido principal
Antes podía usar para vincular y desvincular cuentas de usuario en algunos casos de uso. Auth0 está deprecando esta funcionalidad. A partir de ahora, deberá usar en todos los casos.
Esta deprecación responde a una posible vulnerabilidad de seguridad. Auth0 recomienda encarecidamente que actualice su código lo antes posible.

​
Funcionalidades afectadas

Los cambios en la vinculación de cuentas son los siguientes:
  • Ya no puede usar un token de ID en el encabezado Authorization; en su lugar, debe usar un token de acceso.
  • Si usa un token de acceso en el encabezado Authorization con update:users como permiso concedido, puede enviar en el cuerpo de la solicitud el user_id o el token de ID de la cuenta secundaria.
  • Si usa un token de acceso en el encabezado Authorization con update:current_user_metadata como permiso concedido, solo puede enviar el token de ID de la cuenta secundaria en el cuerpo de la solicitud.
  • Si envía el token de ID de la cuenta secundaria en el cuerpo de la solicitud (los casos de uso descritos en los dos puntos anteriores), debe cumplirse lo siguiente:
    • El token de ID debe estar firmado con RS256 (puede establecer este valor en Dashboard > Clients > Client Settings > Advanced Settings > OAuth.
    • El claim aud del token de ID debe identificar al cliente y tener el mismo valor que el claim azp del token de acceso.
  • Para desvincular cuentas, ya no puede usar un token de ID en el encabezado Authorization. Debe usar un token de acceso en su lugar.
Hay varias maneras de vincular y desvincular cuentas. En la siguiente lista puede ver los casos de uso y cómo los afectan estos cambios.
Caso de usoEstado
Use el endpoint POST /api/v2/users/{id}/identities de Management API y envíe el token de ID de la cuenta principal en el encabezado Authorization.Afectado
Use el endpoint POST /api/v2/users/{id}/identities de Management API y envíe un token de acceso (con scope update:users) en el encabezado authorization, y el user_id de la cuenta secundaria en la carga útil.No afectado
Use el endpoint POST /api/v2/users/{id}/identities de Management API y envíe un token de acceso (con scope update:current_user_identities) en el encabezado Authorization, y el user_id de la cuenta secundaria en la carga útil.Afectado
Use el endpoint POST /api/v2/users/{id}/identities de Management API y envíe un token de acceso en el encabezado Authorization y el token de ID de la cuenta secundaria en la carga útil.Nuevo caso de uso
Use la biblioteca auth0.js y el token de ID de la cuenta principal para crear una instancia de auth0.Management.Afectado
Use la biblioteca auth0.js y un token de acceso (con scope update:users) para crear una instancia de auth0.Management.No afectado
Use la biblioteca auth0.js y un token de acceso (con scope update:current_user_identities) para crear una instancia de auth0.Management.Afectado
Use el endpoint DELETE /api/v2/users/{id}/identities/{provider}/{user_id} de Management API y envíe el token de ID de la cuenta principal en el encabezado Authorization.Afectado
Use el endpoint DELETE /api/v2/users/{id}/identities/{provider}/{user_id} de Management API y envíe un token de acceso en el encabezado Authorization.No afectado

​
Actions

Revise todas las llamadas al endpoint Identities para la vinculación de cuentas y actualice aquellas que usen el flujo vulnerable descrito anteriormente. Puede actualizar sus llamadas de cualquiera de las siguientes maneras:
  • Escenarios de vinculación del lado del cliente o iniciados por el usuario: En los escenarios de vinculación del lado del cliente, haga la llamada al endpoint Identities con un token de acceso con el scope update:current_user_identities y proporcione el token de ID de la cuenta secundaria en la carga útil (link_with). Este token de ID debe obtenerse mediante un flujo /conforme a OIDC.
  • Escenarios de vinculación del lado del servidor: En los escenarios de vinculación del lado del servidor, haga la llamada al endpoint Identities con un token de acceso con el scope update:users y proporcione el user_id de la cuenta secundaria en la carga útil.
Consulte Link User Accounts para obtener más información. Para vincular cuentas de usuario, puede llamar al endpoint para vincular una cuenta de usuario de la o usar la biblioteca Auth0.js. Un caso de uso habitual es permitir que el usuario que ha iniciado sesión vincule sus cuentas mediante su aplicación. Antes de la deprecación, podía usar el token de ID o el token de acceso del usuario principal (que contenía el scope update:current_user_identities) para autenticarse en la Management API y usar el endpoint Link a User Account. Ahora debe obtener un token de acceso (que contenga el scope update:current_user_identities) y usarlo para autenticarse en la API y usar el endpoint Link a User Account. La carga útil debe ser el token de ID del usuario secundario.
  1. Obtenga un token de acceso con el scope update:current_user_identities, como se muestra en el siguiente ejemplo. El ejemplo usa el flujo implícito; sin embargo, puede obtener tokens de acceso para cualquier tipo de aplicación.
  2. Si usaba el método anterior con un token de ID, su código se vería similar a este: Si usa el nuevo método con un token de acceso, su código se verá similar a este:
  3. Para obtener un token de acceso que pueda acceder a la Management API:
    1. Establezca audience en https://{yourDomain}/api/v2/.
    2. Solicite el scope ${scope}.
    3. Establezca response_type en id_token token para que Auth0 envíe tanto un token de ID como un token de acceso. Si decodificamos el token de acceso y revisamos su contenido, podemos ver lo siguiente: Tenga en cuenta que aud está configurado con el URI de la API de su inquilino, scope con ${scope} y sub con el ID de usuario del usuario que ha iniciado sesión.
  4. Debe cumplirse lo siguiente:
    1. El token de ID de la cuenta secundaria debe estar firmado con RS256.
    2. El claim aud del token de ID de la cuenta secundaria debe identificar al cliente y tener el mismo valor que el claim azp del token de acceso usado para realizar la solicitud.
  5. Una vez que tenga el token de acceso, puede usarlo para vincular cuentas de usuario. Esta parte sigue siendo la misma; no cambia nada más en la solicitud, salvo el valor que usa como token Bearer. La respuesta también sigue siendo la misma.
Si utiliza la biblioteca auth0.js para acceder a la Management API y vincular cuentas, probablemente utilice el token de ID de la identidad principal del usuario para crear una instancia de auth0.Management y usarla para vincular cuentas.
  1. Obtenga un token de acceso con el scope update:current_user_identities y úselo para crear una instancia de auth0.Management. La llamada final a linkUser sigue siendo la misma.
  2. Si utiliza el método anterior con un token de ID, su código se verá similar a este: Si utiliza el nuevo método con un token de acceso, su código se verá similar a este:
    1. Solicita tanto un token de ID como un token de acceso como respuesta (responseType: `token id_token`).
    2. Establece la Management API como la audiencia del token (audience: `https://YOUR_DOMAIN/api/v2/`).
    3. Solicita el permiso requerido (scope: `update:current_user_identities`).
    4. Se autentica en la Management API mediante el token de acceso.
Si obtienes un token de acceso para la vinculación de cuentas que contenga el scope update:users y envías el user_id y el provider de la cuenta secundaria en la solicitud, no tienes que hacer ningún cambio. Sin embargo, este nuevo método ofrece una alternativa. Sigues usando un token de acceso que contiene el scope update:users para autenticarte con la API, pero en la carga útil de la solicitud puedes enviar el token de ID de la cuenta secundaria (en lugar de user_id y provider). Se debe cumplir lo siguiente:
  • El token de ID de la cuenta secundaria debe estar firmado con RS256.
  • La claim aud del token de ID de la cuenta secundaria debe identificar al cliente y tener el mismo valor que la claim azp del token de acceso utilizado para realizar la solicitud.
Si usa tokens de ID para desvincular cuentas, debe actualizar su código para usar tokens de acceso.
  1. Primero, debe obtener un token de acceso con el scope update:current_user_identities.
  2. Con el método anterior, que usa un token de ID, su código se vería similar a esto: Con el nuevo método, que usa un token de acceso, su código se verá similar a esto:
  3. Para obtener un token de acceso que pueda acceder a la Management API:
    1. Establezca la audience en https://{yourDomain}/api/v2/.
    2. Solicite el scope ${scope}.
    3. Establezca response_type en id_token token para que Auth0 envíe tanto un token de ID como un token de acceso. Si decodificamos el token de acceso y revisamos su contenido, podemos ver lo siguiente: Tenga en cuenta que aud está establecido en el URI de la API de su inquilino, scope en update:current_user_identities y sub en el ID de usuario del usuario que inició sesión.
  4. Una vez que tenga el token de acceso, puede llamar al endpoint para desvincular una identidad de usuario de la Management API, usándolo en el encabezado Authorization.
  5. Con el método anterior, la llamada se vería similar a esto: 
    DELETE https://YOUR_DOMAIN/api/v2/users/{primaryAccountUserId}/identities/{secondaryAccountProvider}/{secondaryAccountUserId}
    Authorization: 'Bearer {yourIdTokenOrMgmtApiAccessToken}'
    Con el nuevo método, la llamada se verá similar a esto:

​
Consideraciones de seguridad

Hemos identificado una debilidad en un flujo concreto de vinculación de cuentas que podría permitir su uso indebido en determinadas circunstancias. No hemos encontrado indicios de que se haya utilizado de forma maliciosa, pero hemos decidido dejar obsoleto este flujo para evitar que eso llegue a ocurrir. Por lo tanto, Auth0 exige a los clientes que utilicen el flujo de vinculación de cuentas afectado que migren a una implementación más segura antes del 19 de octubre de 2018. En esta guía se describen las rutas de migración, que no deberían suponer ninguna pérdida de funcionalidad. A partir del 19 de octubre de 2018, el flujo de vinculación de cuentas afectado se deshabilitará y se producirán errores en tiempo de ejecución. Se verá afectado si llama al endpoint Post Identities mediante un token (ID o token de acceso) con el scope update:current_user_identities en el encabezado Authorization e incluye el user_id de la cuenta secundaria en la carga útil. No se verá afectado ningún otro caso de uso.

​
Más información