Passer au contenu principal
Si vous utilisez une version de Lock antérieure à 11 et une version d’Auth0.js antérieure à 9, vous pouvez utiliser d’anciens flux d’authentification désormais obsolètes. Auth0 recommande de migrer votre code des anciennes versions d’Auth0.js et de Lock vers les nouvelles API conformes à OIDC.

​
Renouvelez les jetons

Les anciennes applications 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 anciennes applications 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 indiquer l’identifiant de l’API dans le paramètre audience lors de l’initialisation d’auth0.js ou de Lock. Si vous spécifiez une , le flux OIDC sera déclenché et les données de profil utilisateur renvoyées par Auth0 dans les ID tokens ou par /userinfo seront conformes à OIDC. Si votre application utilise une revendication non standard du profil utilisateur, elle cessera de fonctionner. Consultez la section Appeler une API de nos guides de démarrage rapide SPA pour en savoir plus sur la façon d’appeler des API à partir de SPA. Vous devrez également migrer l’implémentation de votre API backend pour utiliser des jetons d’accès. Consultez les guides de démarrage rapide de l’API pour savoir comment procéder.

​
Profils utilisateur

Les anciens flux d’authentification qui permettent aux ID Tokens et au point de terminaison /userinfo d’inclure le profil utilisateur complet sont obsolètes. Assurez-vous que l’option Legacy User Profile est désactivée après avoir terminé la migration vers les nouvelles API conformes à OIDC. Lorsque vous utilisez les anciens flux d’authentification, 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 à certains claims standard d’être inclus 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 tous les claims dont vous avez besoin soient disponibles dans votre application. Notez que vous pouvez ajouter des claims personnalisés 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 la (au lieu d’obtenir le profil via le flux d’authentification), comme décrit dans la section suivante.

​
Profil utilisateur avec Management API

Dans les anciens flux, la Management API prenait en charge l’authentification avec un ID Token. Cette approche est maintenant obsolète, et vous devez désormais l’appeler 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’authentification; vous devrez donc continuer à utiliser l’audience d’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 pour 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 lors de l’appel à checkSession(). Si c’est le cas, assurez-vous que l’option Allow Skipping User Consent est activée pour la Management API et que vous n’exécutez pas cela depuis localhost.