Saltar al contenido principal
Si usa versiones de Lock anteriores a la 11 y versiones de Auth0.js anteriores a la 9, puede utilizar flujos de autenticación heredados que están obsoletos. Auth0 recomienda migrar el código de versiones anteriores de Auth0.js y Lock a las nuevas API compatibles con OIDC.

​
Renovar tokens

Las aplicaciones heredadas usaban y la función refreshToken() para obtener nuevos tokens cuando vencían los anteriores (a continuación se muestra un ejemplo). En auth0.js v9 y Lock 11, debes usar Autenticación silenciosa y checkSession() (a continuación se muestra un ejemplo).

​
Llamar a las API

Las aplicaciones heredadas usaban un para invocar API. Esto es una mala práctica, y recomendamos usar únicamente . Para llamar a una API, deberá especificar el identificador de la API como el parámetro audience al inicializar auth0.js o Lock. Si especifica una , se activará el flujo OIDC y los datos del perfil del usuario que Auth0 devuelve en los ID Token o desde /userinfo se ajustarán a OIDC. Si su aplicación usa algún claim no estándar del perfil del usuario, dejará de funcionar. Consulte la sección Llamar a una API de nuestras SPA Quickstarts para obtener más información sobre cómo llamar a API desde una SPA. También deberá migrar la implementación de su API de backend para usar tokens de acceso. Consulte API Quickstarts para ver instrucciones sobre cómo hacerlo.

​
Perfiles de usuario

Los flujos de autenticación heredados que permiten que los ID Tokens y el endpoint /userinfo incluyan el perfil completo del usuario están quedando obsoletos. Asegúrate de que el interruptor Legacy User Profile esté desactivado después de completar la migración a las nuevas API conformes con OIDC. Al usar los flujos de autenticación heredados, el perfil completo del usuario se devuelve en los ID Tokens y desde /userinfo, como se muestra a continuación. El nuevo perfil de usuario cumple con la especificación OIDC, que permite que ciertos claims estándar estén disponibles en la respuesta. El contenido variará según los alcances solicitados. Tendrás que ajustar los alcances que solicitas al configurar Auth0.js o Lock para que todos los claims que necesitas estén disponibles en tu aplicación. Ten en cuenta que puedes agregar custom claims para devolver cualquier dato que quieras (por ejemplo, metadatos del usuario). Otro enfoque para obtener el perfil completo del usuario es usar la (en lugar de obtener el perfil a través del flujo de autenticación), como se describe en la siguiente sección.

​
Perfil de usuario con Management API

En los flujos heredados, la Management API admitía la autenticación con un ID Token. Este enfoque ha quedado obsoleto y ahora debes invocarla con un Token de acceso. Para obtener un Token de acceso, debes solicitar uno a Auth0 usando la audiencia https://{yourDomain}/api/v2/. Actualmente, Auth0 no admite especificar dos audiencias durante la autenticación, por lo que tendrás que seguir usando la audiencia de la API de tu aplicación al inicializar Lock o auth0.js. Una vez que el usuario se haya autenticado, puedes usar checkSession para recuperar un access_token de la Management API y luego llamar al endpoint getUser(). Puedes solicitar los siguientes alcances:
  • read:current_user
  • update:current_user_identities
  • create:current_user_metadata
  • update:current_user_metadata
  • delete:current_user_metadata
  • create:current_user_device_credentials
  • delete:current_user_device_credentials
Es posible que obtengas un error consent_required al llamar a checkSession(). Si es así, asegúrate de tener habilitada la opción Allow Skipping User Consent para la Management API y de no estar ejecutando la aplicación desde localhost.