Migrer vers les jetons d’accès pour la liaison de comptes

​

Fonctionnalités touchées

• Vous ne pouvez plus utiliser un ID token dans l’en-tête Authorization; vous devez utiliser un access token à la place.
• Si vous utilisez un access token dans l’en-tête Authorization avec update:users comme permission accordée, vous pouvez envoyer dans le corps de la request soit le user_id, soit l’ID token du compte secondaire.
• Si vous utilisez un access token dans l’en-tête Authorization avec update:current_user_metadata comme permission accordée, vous pouvez seulement envoyer l’ID token du compte secondaire dans le corps de la request.
• Si vous envoyez l’ID token du compte secondaire dans le corps de la request (les cas d’utilisation décrits dans les deux puces précédentes), les conditions suivantes doivent être respectées :
  • L’ID token doit être signé à l’aide de RS256 (vous pouvez définir cette valeur dans Dashboard > Clients > Client Settings > Advanced Settings > OAuth.
  • Le claim aud de l’ID Token doit identifier le client et avoir la même valeur que le claim azp de l’access token.
• Pour dissocier des comptes, vous ne pouvez plus utiliser un ID token dans l’en-tête Authorization. Vous devez utiliser un access token à la place.

​

Actions

• Scénarios de liaison côté client / lancés par l’utilisateur : Pour les scénarios de liaison côté client, effectuez la requête vers le point de terminaison Identities à l’aide d’un jeton d’accès avec la portée update:current_user_identities, et fournissez le jeton ID du compte secondaire dans la charge utile (link_with). Ce jeton ID doit être obtenu au moyen d’un flux conforme à OAuth/OIDC.
• Scénarios de liaison côté serveur : Pour les scénarios de liaison côté serveur, effectuez la requête vers le point de terminaison Identities à l’aide d’un jeton d’accès avec la portée update:users et fournissez le user_id du compte secondaire dans la charge utile.

​

Lier des comptes d’utilisateur

​

Lier les comptes de l’utilisateur courant avec la Management API

1. Obtenez un jeton d’accès avec la portée update:current_user_identities, comme dans l’exemple suivant. L’exemple utilise le flux implicite, mais vous pouvez obtenir des jetons d’accès pour tout type d’application.
2. Avec l’ancienne méthode utilisant un ID token, votre code ressemblerait à ceci : Avec la nouvelle méthode utilisant un jeton d’accès, votre code ressemblera à ceci :
3. Pour obtenir un jeton d’accès qui peut accéder à la Management API :
   1. Définissez audience sur https://{yourDomain}/api/v2/.
   2. Demandez le scope ${scope}.
   3. Définissez response_type sur id_token token afin qu’Auth0 envoie à la fois un ID token et un jeton d’accès. Si nous décodons le jeton d’accès et examinons son contenu, nous pouvons voir ce qui suit : Remarquez que aud est défini sur l’URI de l’API de votre tenant, scope sur ${scope} et sub sur l’ID de l’utilisateur connecté.
4. Les conditions suivantes doivent être respectées :
   1. L’ID token du compte secondaire doit être signé avec RS256.
   2. La claim aud dans l’ID token du compte secondaire doit identifier le client et avoir la même valeur que la claim azp du jeton d’accès utilisé pour effectuer la requête.
5. Une fois que vous avez le jeton d’accès, vous pouvez l’utiliser pour lier des comptes d’utilisateur. Cette partie reste inchangée : rien d’autre ne change dans la requête, sauf la valeur utilisée comme jeton Bearer. La réponse demeure également la même.

​

Lier les comptes de l’utilisateur actuel avec auth0.js

1. Obtenez un jeton d’accès avec le scope update:current_user_identities, puis utilisez ce jeton pour instancier auth0.Management. La requête finale à linkUser reste la même.
2. Avec l’ancienne méthode utilisant un ID token, votre code ressemblerait à ceci : Avec la nouvelle méthode utilisant un jeton d’accès, votre code ressemblera à ceci :
   1. Demande à la fois un ID token et un jeton d’accès dans la réponse (responseType: `token id_token`).
   2. Définit la Management API comme audience du jeton (audience: `https://YOUR_DOMAIN/api/v2/`).
   3. Demande la permission requise (scope: `update:current_user_identities`).
   4. S’authentifie auprès de la Management API à l’aide du jeton d’accès.

​

Lier n’importe quel compte d’utilisateur avec la Management API

• Le jeton d’ID du compte secondaire doit être signé avec RS256.
• Le claim aud du jeton d’ID du compte secondaire doit identifier le client et avoir la même valeur que le claim azp du jeton d’accès utilisé pour effectuer la requête.

​

Dissocier des comptes d’utilisateur

1. Vous devez d’abord obtenir un jeton d’accès avec la portée update:current_user_identities.
2. Avec l’ancienne méthode utilisant un jeton ID, votre code ressemblerait à ceci : Avec la nouvelle méthode utilisant un jeton d’accès, votre code ressemblera à ceci :
3. Pour obtenir un jeton d’accès permettant d’accéder à la Management API :
   1. Définissez audience sur https://{yourDomain}/api/v2/.
   2. Demandez la scope ${scope}.
   3. Définissez response_type sur id_token token afin qu’Auth0 envoie à la fois un jeton ID et un jeton d’accès. Si nous décodons le jeton d’accès et en examinons le contenu, nous pouvons voir ce qui suit : Notez que aud est défini sur l’URI de l’API de votre tenant, que scope est défini sur update:current_user_identities et que sub correspond à l’ID utilisateur de l’utilisateur connecté.
4. Une fois le jeton d’accès obtenu, vous pouvez envoyer une requête au point de terminaison Dissocier une identité d’utilisateur de la Management API, en l’incluant dans l’en-tête Authorization.
5. Avec l’ancienne méthode, votre requête ressemblerait à ceci :
   DELETE https://YOUR_DOMAIN/api/v2/users/{primaryAccountUserId}/identities/{secondaryAccountProvider}/{secondaryAccountUserId}
       Authorization: 'Bearer {yourIdTokenOrMgmtApiAccessToken}'
   
   Avec la nouvelle méthode, votre requête ressemblera à ceci :

​

Considérations de sécurité

​

En savoir plus

• Migrer vers les points de terminaison de la Management API à l’aide de jetons d’accès