Migrer depuis des flux d’authentification hérités

Lorsque vous utilisez des versions de Lock antérieures à 11 et Auth0.js antérieures à 9, il est possible que vous utilisiez certains flux d’authentification hérités, qui sont obsolètes. Auth0 recommande de migrer le code des anciennes versions d’Auth0.js et de Lock vers les nouvelles API conformes à l’OIDC.

Les applications héritées utilisaient les jetons d’actualisation et la fonction refreshToken() pour obtenir de nouveaux jetons à l’expiration (voir l’exemple ci-dessous).

Dans auth0.js v9 et Lock 11, vous devez utiliser Authentification silencieuse et checkSession() (voir exemple ci-dessous).

Les applications héritées utilisaient un jeton d’ID pour invoquer les API. Il s’agit d’une mauvaise pratique, et nous vous recommandons de n’utiliser que des jetons d’accès.

Pour appeler une API, vous devrez spécifier l’identifiant de l’API en tant que paramètre audience lors de l’initialisation d’auth0.js ou de Lock.

Si vous spécifiez une audience, le flux OIDC sera déclenché et les données de profil utilisateur renvoyées par Auth0 dans des jetons d’ID ou à partir de /userinfo seront conformes à l’OIDC. Si votre application utilise une demande non standard du profil utilisateur, elle sera interrompue.

Voir la section Appeler une API de notre guide de Démarrage rapide pour les applications à page unique pour plus d’informations sur la manière d’appeler des API à partir d’une application à page unique. Vous devrez également migrer votre implémentation dorsale d’API pour utiliser des jetons d’accès. Reportez-vous à la section Démarrage rapide - API pour savoir comment procéder.

Les flux d’authentification hérités qui permettent aux jetons d’ID et au point de terminaison /userinfo d’inclure le profil utilisateur complet sont obsolètes. Assurez-vous que le bouton à bascule Legacy User Profile (Profil utilisateur hérité) est désactivé après avoir effectué la migration vers les nouvelles API conformes à l’OIDC.

Lors de l’utilisation des flux d’authentification hérités, le profil utilisateur complet est renvoyé dans les jetons d’ID et à partir de /userinfo, comme indiqué ci-dessous.

Le nouveau profil utilisateur est conforme à la spécification OIDC, ce qui permet à certaines demandes standard d’être disponibles dans la réponse.

Le contenu variera en fonction des permissions demandées. Vous devrez ajuster les permissions demandées lors de la configuration d’Auth0.js ou de Lock afin que toutes les demandes dont vous avez besoin soient disponibles dans votre application. Notez que vous pouvez ajouter des demandes personnalisées pour renvoyer les données que vous souhaitez (par exemple, les métadonnées de l’utilisateur).

Une autre approche pour obtenir le profil utilisateur complet consiste à utiliser Management API (au lieu d’obtenir le profil par le biais du flux d’authentification), comme décrit dans la section suivante.

Dans les flux hérités, Management API prenait en charge l’authentification à l’aide d’un jeton d’ID. Cette approche a été abandonnée et vous devez maintenant l’appeler avec un jeton d’accès.

Pour obtenir un jeton d’accès, vous devez le demander à Auth0 en utilisant l’audience https://{yourDomain}/api/v2/. Auth0 ne prend pas actuellement en charge la spécification de deux audiences lors de l’authentification, vous devrez donc toujours utiliser l’audience API de votre application lors de l’initialisation de Lock ou d’auth0.js. Une fois l’utilisateur authentifié, vous pouvez utiliser checkSession pour récupérer un access_token de Management API, puis appeler le point de terminaison getUser().

Vous pouvez demander les permissions suivantes :

• 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

Vous pourriez obtenir une erreur consent_required lorsque vous appelez checkSession(). Si c’est le cas, assurez-vous que Allow Skipping User Consent (Ignorer le consentement de l’utilisateur) est activé pour Management API et que vous n’exécutez pas à partir de localhost.