> ## Documentation Index
> Fetch the complete documentation index at: https://translations.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

> Décrit comment migrer des flux d’authentification hérités.

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

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.

<div id="renew-tokens">
  ## Renouveler les jetons
</div>

Les applications héritées utilisaient les <Tooltip tip="Jeton d’actualisation : jeton utilisé pour obtenir un nouveau jeton d’accès sans obliger les utilisateurs à se reconnecter." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=Refresh+Tokens">jetons d’actualisation</Tooltip> 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](/docs/fr-ca/authenticate/login/configure-silent-authentication) et `checkSession()`(vous trouverez un exemple ci-dessous).

<div id="call-apis">
  ## Appeler des API
</div>

Les applications héritées utilisaient un <Tooltip tip="ID token : jeton destiné au client lui-même plutôt qu’à l’accès à une ressource." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=ID+token">ID token</Tooltip> pour appeler des API. Il s’agit d’une mauvaise pratique, et nous vous recommandons d’utiliser uniquement des <Tooltip tip="Jetons d’accès : justificatif d’autorisation, sous la forme d’une chaîne opaque ou d’un JWT, utilisé pour accéder à une API." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=access+tokens">jetons d’accès</Tooltip>.

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 <Tooltip tip="Audience : identifiant unique de l’audience d’un jeton émis. Nommée aud dans un jeton, sa valeur contient l’ID d’une application (Client ID) pour un ID token ou d’une API (API identifier) pour un jeton d’accès." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=audience">audience</Tooltip>, 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.

<div id="user-profiles">
  ## Profils utilisateur
</div>

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](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) 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 <Tooltip tip="Management API : un produit qui permet aux clients d’effectuer des tâches administratives." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=Management+API">Management API</Tooltip> (au lieu d’obtenir le profil par le flux d’authentification), comme décrit dans la section suivante.

<div id="user-profile-with-management-api">
  ## Profil utilisateur avec Management API
</div>

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.