Passer au contenu principal
Auparavant, vous pouviez utiliser pour lier et délier des comptes d’utilisateur dans certains cas d’utilisation. Auth0 entame la dépréciation de cette fonctionnalité. Vous devrez désormais utiliser des dans tous les cas.
Cette dépréciation est due à une vulnérabilité de sécurité potentielle. Auth0 vous recommande fortement de mettre à jour votre code dès que possible.

​
Fonctionnalités concernées

Les changements apportés à la liaison de comptes sont les suivants :
  • Vous ne pouvez plus utiliser un jeton d’identité dans l’en-tête Authorization; vous devez plutôt utiliser un jeton d’accès.
  • Si vous utilisez un jeton d’accès dans l’en-tête Authorization avec update:users comme permission accordée, vous pouvez envoyer dans le corps de la requête soit le user_id, soit le jeton d’identité du compte secondaire.
  • Si vous utilisez un jeton d’accès dans l’en-tête Authorization avec update:current_user_metadata comme permission accordée, vous pouvez envoyer uniquement le jeton d’identité du compte secondaire dans le corps de la requête.
  • Si vous envoyez le jeton d’identité du compte secondaire dans le corps de la requête (les cas d’utilisation décrits dans les deux puces précédentes), les conditions suivantes doivent être respectées :
    • Le jeton d’identité doit être signé avec RS256 (vous pouvez définir cette valeur dans Auth0 Dashboard > Clients > Client Settings > Advanced Settings > OAuth).
    • La revendication aud du jeton d’identité doit identifier l’application et avoir la même valeur que la revendication azp du jeton d’accès.
  • Pour dissocier des comptes, vous ne pouvez plus utiliser un jeton d’identité dans l’en-tête Authorization. Vous devez plutôt utiliser un jeton d’accès.
Il existe plusieurs façons de lier et de dissocier des comptes. La liste suivante présente les cas d’utilisation et l’incidence de ces changements sur chacun d’eux.
Cas d’utilisationStatut
Utiliser le point de terminaison POST /api/v2/users/{id}/identities du Management API et envoyer le jeton d’identité du compte principal dans l’en-tête Authorization.Concerné
Utiliser le point de terminaison POST /api/v2/users/{id}/identities du Management API et envoyer un jeton d’accès (avec le scope update:users) dans l’en-tête authorization, ainsi que le user_id du compte secondaire dans le payload.Non concerné
Utiliser le point de terminaison POST /api/v2/users/{id}/identities du Management API et envoyer un jeton d’accès (avec le scope update:current_user_identities) dans l’en-tête Authorization, ainsi que le user_id du compte secondaire dans le payload.Concerné
Utiliser le point de terminaison POST /api/v2/users/{id}/identities du Management API et envoyer un jeton d’accès dans l’en-tête Authorization, ainsi que le jeton d’identité du compte secondaire dans le payload.Nouveau cas d’utilisation
Utiliser la bibliothèque auth0.js et le jeton d’identité du compte principal pour instancier auth0.Management.Concerné
Utiliser la bibliothèque auth0.js et un jeton d’accès (avec le scope update:users) pour instancier auth0.Management.Non concerné
Utiliser la bibliothèque auth0.js et un jeton d’accès (avec le scope update:current_user_identities) pour instancier auth0.Management.Concerné
Utiliser le point de terminaison DELETE /api/v2/users/{id}/identities/{provider}/{user_id} du Management API et envoyer le jeton d’identité du compte principal dans l’en-tête Authorization.Concerné
Utiliser le point de terminaison DELETE /api/v2/users/{id}/identities/{provider}/{user_id} du Management API et envoyer un jeton d’accès dans l’en-tête Authorization.Non concerné

​
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 ou l’autre des façons suivantes :
  • Scénarios de liaison côté client / initiés par l’utilisateur : Pour les scénarios de liaison côté client, effectuez l’appel au point de terminaison Identities à l’aide d’un jeton d’accès avec le scope update:current_user_identities, et fournissez le jeton d’identité du compte secondaire dans le payload (link_with). Ce jeton d’identité 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 l’appel au point de terminaison Identities à l’aide d’un jeton d’accès avec le scope update:users et fournissez le user_id du compte secondaire dans le payload.
Consultez Link User Accounts pour en savoir plus. Pour lier des comptes d’utilisateur, vous pouvez soit appeler le point de terminaison Link a User Account du , 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 le jeton d’identité ou le jeton d’accès de l’utilisateur principal (qui contenait le scope update:current_user_identities) pour vous authentifier auprès de la Management API et utiliser le point de terminaison Link a User Account. Vous devez maintenant obtenir un jeton d’accès (contenant le scope update:current_user_identities) et l’utiliser pour vous authentifier auprès de l’API, puis utiliser le point de terminaison Link a User Account. Le payload doit être le jeton d’identité de l’utilisateur secondaire.
  1. Obtenez un jeton d’accès avec le scope update:current_user_identities, comme illustré dans l’exemple suivant. L’exemple utilise le flux implicite; toutefois, vous pouvez obtenir des jetons d’accès pour tout type d’application.
  2. Avec la méthode précédente utilisant un jeton d’identité, 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 pouvant 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 jeton d’identité 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 : Notez que aud est défini sur l’URI de l’API de votre locataire, scope sur ${scope} et sub sur l’ID utilisateur de l’utilisateur connecté.
  4. Les conditions suivantes doivent être respectées :
    1. Le jeton d’identité du compte secondaire doit être signé avec RS256.
    2. La revendication aud dans le jeton d’identité du compte secondaire doit identifier l’application et avoir la même valeur que la revendication 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 utilisateur. Cette partie demeure 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 jeton d’identité de l’identité principale de l’utilisateur pour instancier auth0.Management et vous en servir pour lier des comptes.
  1. Obtenez un jeton d’accès avec le scope update:current_user_identities, puis utilisez-le pour instancier auth0.Management. L’appel final à linkUser reste le même.
  2. Avec l’ancienne méthode utilisant un jeton d’identité, votre code ressemblerait à ceci : Avec la nouvelle méthode utilisant un jeton d’accès, votre code ressemblera à ceci :
    1. Demande qu’un jeton d’identité et un jeton d’accès soient tous deux renvoyés en réponse (responseType: `token id_token`).
    2. Définit la Management API comme audience cible du jeton (audience: `https://YOUR_DOMAIN/api/v2/`).
    3. Demande l’autorisation 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 aucune modification à apporter. Cependant, cette nouvelle méthode offre une autre possibilité. Vous utilisez toujours un jeton d’accès qui contient 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’identité du compte secondaire (au lieu du user_id et du provider). Les conditions suivantes doivent être remplies :
  • Le jeton d’identité du compte secondaire doit être signé avec RS256.
  • La revendication aud du jeton d’identité du compte secondaire doit identifier l’application et avoir la même valeur que la revendication azp du jeton d’accès utilisé pour effectuer la requête.
Si vous utilisez des ID tokens pour dissocier des comptes, vous devez mettre à jour votre code pour utiliser des jetons d’accès.
  1. Vous devez d’abord obtenir un jeton d’accès avec le scope update:current_user_identities.
  2. Avec l’ancienne méthode qui utilisait un ID token, votre code ressemblerait à ceci : Avec la nouvelle méthode qui utilise un jeton d’accès, votre code ressemblera à ceci :
  3. Pour obtenir un jeton d’accès pouvant 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 jeton d’identité 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 locataire, scope sur update:current_user_identities et sub sur l’ID utilisateur de l’utilisateur connecté.
  4. Une fois que vous avez le jeton d’accès, vous pouvez appeler l’endpoint Dissocier une identité utilisateur de la Management API en l’utilisant dans l’en-tête Authorization.
  5. Avec l’ancienne méthode, votre appel ressemblerait à ceci : 
    DELETE https://YOUR_DOMAIN/api/v2/users/{primaryAccountUserId}/identities/{secondaryAccountProvider}/{secondaryAccountUserId}
    Authorization: 'Bearer {yourIdTokenOrMgmtApiAccessToken}'
    Avec la nouvelle méthode, votre appel 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 dans certaines circonstances. Nous n’avons trouvé aucune preuve d’utilisation malveillante, mais nous avons décidé de déprécier 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 concerné migrent vers une implémentation plus sécurisée 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 concerné sera désactivé et vous rencontrerez des erreurs d’exécution. Vous êtes concerné si vous appelez le endpoint Post Identities à l’aide d’un jeton (ID ou jeton d’accès) avec le scope update:current_user_identities dans l’en-tête Authorization, et que vous incluez le user_id du compte secondaire dans le payload. Aucun autre cas d’utilisation n’est concerné.

​
En savoir plus