Skip to main content
Si vous utilisez une version de Lock antérieure à 11 et une version d’Auth0.js antérieure à 9, vous pourriez utiliser des flux d’authentification hérités désormais déconseillés. Auth0 recommande de migrer le code des anciennes versions d’Auth0.js et de Lock vers les nouvelles API conformes à OIDC.

​
Renouveler les jetons

Les applications héritées utilisaient les et la fonction refreshToken() pour obtenir de nouveaux jetons lorsqu’ils expiraient (vous trouverez un exemple ci-dessous). Dans auth0.js v9 et Lock 11, vous devez utiliser l’authentification silencieuse et checkSession()(vous trouverez un exemple ci-dessous).

​
Appeler des API

Les applications héritées utilisaient un pour appeler des API. Il s’agit d’une mauvaise pratique, et nous vous recommandons d’utiliser uniquement des . Pour appeler une API, vous devez préciser l’identifiant de l’API comme paramètre audience lors de l’initialisation d’auth0.js ou de Lock. Si vous précisez une , le flux OIDC sera déclenché et les données du profil utilisateur renvoyées par Auth0 dans les ID tokens ou depuis /userinfo seront conformes à OIDC. Si votre application utilise un claim non standard du profil utilisateur, cela cessera de fonctionner. Consultez la section Appeler une API de nos Quickstarts pour les SPA pour en savoir plus sur la façon d’appeler des API à partir de SPA. Vous devrez aussi migrer la mise en œuvre de votre backend API afin d’utiliser des jetons d’accès. Consultez les Quickstarts API pour savoir comment procéder.

​
Profils utilisateur

Les flux d’authentification hérités qui permettent aux ID Tokens et au point de terminaison /userinfo d’inclure le profil utilisateur complet sont en cours de dépréciation. Assurez-vous que la bascule Legacy User Profile est désactivée après avoir terminé la migration vers les nouvelles API conformes à OIDC. Lorsque vous utilisez les flux d’authentification hérités, le profil utilisateur complet est renvoyé dans les ID Tokens et par /userinfo, comme illustré ci-dessous. Le nouveau profil utilisateur est conforme à la spécification OIDC, ce qui permet à certaines claims standards d’être présentes dans la réponse. Le contenu varie selon les scopes demandés. Vous devrez ajuster les scopes que vous demandez lors de la configuration d’Auth0.js ou de Lock afin que toutes les claims dont vous avez besoin soient disponibles dans votre application. Notez que vous pouvez ajouter des claims personnalisées pour renvoyer les données de votre choix (par exemple, les métadonnées utilisateur). Une autre façon d’obtenir le profil utilisateur complet consiste à utiliser l’outil (au lieu d’obtenir le profil par le flux d’authentification), comme décrit dans la section suivante.

​
Profil utilisateur avec Management API

Dans les flux d’authentification hérités, la Management API prenait en charge l’authentication avec un ID Token. Cette approche est désormais déconseillée, et vous devez maintenant lui envoyer une requête avec un jeton d’accès. Pour obtenir un jeton d’accès, vous devez en demander un à Auth0 en utilisant l’audience https://{yourDomain}/api/v2/. Auth0 ne prend actuellement pas en charge la spécification de deux audiences lors de l’authentication; vous devrez donc continuer à utiliser l’audience API de votre application lorsque vous initialisez Lock ou auth0.js. Une fois l’utilisateur authentifié, vous pouvez utiliser checkSession pour récupérer un access_token de la Management API, puis appeler le point de terminaison getUser(). Vous pouvez demander les scopes suivants :
  • 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
Il se peut que vous obteniez une erreur consent_required lorsque vous appelez checkSession(). Si c’est le cas, assurez-vous que Allow Skipping User Consent est activé pour la Management API et que vous n’exécutez pas l’application à partir de localhost.