Skip to main content
Auparavant, vous pouviez utiliser les pour lier et dissocier des comptes d’utilisateur dans certains cas d’utilisation. Auth0 abandonne progressivement cette fonctionnalité. Vous devrez désormais utiliser des dans tous les cas.
Cette dépréciation vise à répondre à une vulnérabilité de sécurité potentielle. Auth0 vous recommande fortement de mettre à jour votre code dès que possible.

​
Fonctionnalités touchées

Les changements apportés à la liaison de comptes sont les suivants :
  • 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.
Il existe plusieurs façons de lier et de dissocier des comptes. Dans la liste suivante, vous pouvez voir les cas d’utilisation et la façon dont ces changements les affectent.

​
Actions

Passez en revue tous vos appels au point de terminaison Identities pour la liaison de comptes et mettez à jour ceux qui utilisent le flux vulnérable décrit ci-dessus. Vous pouvez mettre à jour vos appels de l’une des façons suivantes :
  • 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 à /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.
Consultez Lier des comptes d’utilisateur pour en savoir plus. Pour lier des comptes d’utilisateur, vous pouvez soit effectuer une requête au point de terminaison Link a User Account de l’, soit utiliser la bibliothèque auth0.js. Un cas d’utilisation courant consiste à permettre à l’utilisateur connecté de lier ses comptes à l’aide de votre application. Avant la dépréciation, vous pouviez utiliser l’ID token ou le jeton d’accès de l’utilisateur principal (qui contenait la portée update:current_user_identities) pour vous authentifier auprès de la Management API et utiliser le endpoint Link a User Account. Vous devez maintenant obtenir un jeton d’accès (contenant la portée update:current_user_identities) et l’utiliser pour vous authentifier auprès de l’API afin d’utiliser l’endpoint Link a User Account. La charge utile doit être l’ID token de l’utilisateur secondaire.
  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.
Si vous utilisez la bibliothèque auth0.js pour accéder à la Management API et lier des comptes, vous utilisez probablement le ID token de l’identité principale de l’utilisateur pour instancier auth0.Management et l’utiliser pour lier des comptes.
  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.
Si vous obtenez un jeton d’accès pour la liaison de comptes qui contient le scope update:users et que vous envoyez le user_id et le provider du compte secondaire dans la requête, vous n’avez rien à changer. Cependant, cette nouvelle méthode offre une autre possibilité. Vous utilisez toujours un jeton d’accès contenant le scope update:users pour vous authentifier auprès de l’API, mais dans le payload de la requête, vous pouvez envoyer le jeton d’ID du compte secondaire (au lieu de user_id et provider).
Vous utilisez l’Auth0 CLI ? Si ce n’est pas déjà fait, configurez et authentifiez votre session CLI avant d’exécuter cette commande.
Les conditions suivantes doivent être respectées :
  • 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.
Si vous utilisez des jetons ID pour dissocier des comptes, vous devez mettre à jour votre code afin d’utiliser des jetons d’accès.
  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 :
    Avec la nouvelle méthode, votre requête ressemblera à ceci :

​
Considérations de sécurité

Nous avons identifié une faiblesse dans un flux particulier de liaison de comptes qui pourrait être exploitée de façon abusive dans certaines circonstances. Nous n’avons trouvé aucune preuve d’utilisation malveillante, mais nous avons décidé de retirer ce flux afin d’éviter que cela ne se produise. Par conséquent, Auth0 exige que les clients qui utilisent le flux de liaison de comptes touché migrent vers une mise en œuvre plus sécuritaire avant le 19 octobre 2018. Des options de migration sont fournies dans ce guide et ne devraient entraîner aucune perte de fonctionnalité. À compter du 19 octobre 2018, le flux de liaison de comptes touché sera désactivé et vous obtiendrez des erreurs à l’exécution. Vous êtes touché si vous envoyez une requête au endpoint Post Identities à l’aide d’un token (ID ou jeton d’accès) avec la portée update:current_user_identities dans l’en-tête Authorization et incluez le user_id du compte secondaire dans la charge utile. Aucun autre cas d’utilisation n’est touché.

​
En savoir plus