> ## Documentation Index
> Fetch the complete documentation index at: https://auth0.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Migrer depuis des flux d’authentification hérités
> Décrit comment migrer à partir de 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.
## Jetons de renouvellement
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](/docs/fr-ca/authenticate/login/configure-silent-authentication) et `checkSession()` (voir exemple ci-dessous).
## Appeler des API
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.
## Profils utilisateurs
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](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) 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.
## Obtenir le profil utilisateur avec Management API
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.