Comment installer, initialiser et utiliser auth0.js v9
Auth0.js est une bibliothèque JavaScript côté client pour Auth0. Elle prend en charge la connexion hébergée et la connexion intégrée.La documentation complète de l’API de la bibliothèque est accessible ici.
La connexion intégrée pour les applications web utilise l’authentification inter-origines, sauf si vous configurez un domaine personnalisé pour votre locataire. L’authentification inter-origines utilise des témoins tiers pour permettre des transactions d’authentification sécurisées entre différentes origines.
Le répertoire d’exemples de la bibliothèque auth0.js est une application prête à l’emploi qui vous permet d’essayer auth0.js rapidement et facilement. Pour l’exécuter, suivez ces quelques étapes :
Si node n’est pas installé, installez-le maintenant.
Installez les dépendances en exécutant npm install à partir de la racine de ce projet.
Enfin, exécutez npm start à partir de la racine de ce projet, puis accédez à votre application qui s’exécute sur le serveur node, probablement à l’adresse http://localhost:3000/example.
Configurez votre application Auth0 pour la connexion intégrée
Lors de la mise en œuvre de la connexion intégrée, la bibliothèque utilisera des appels inter-origines dans des iframes masquées pour effectuer l’authentification. Pour que cela puisse être fait en toute sécurité, Auth0 doit connaître les domaines sur lesquels vous hébergerez vos applications.Ajoutez le domaine au champ Origines Web autorisées. Vous trouverez ce champ dans la section Paramètres de l’application de votre Auth0 Dashboard.
Plusieurs options s’offrent à vous pour utiliser auth0.js dans votre projet. Choisissez celle qui correspond le mieux à vos besoins parmi les options ci-dessous :Installez-le avec npm ou yarn :
npm install auth0-jsyarn add auth0-js
Après avoir installé le module auth0-js, vous devrez l’inclure dans votre bundle avec toutes ses dépendances ou l’importer au moyen de :
import auth0 from 'auth0-js';
Vous pouvez aussi inclure le script depuis notre CDN :
Deux paramètres obligatoires doivent être fournis dans l’objet options lors de l’instanciation de webAuth; les autres sont facultatifs.
Paramètre
Obligatoire
Description
domain
obligatoire
(String) Le domaine de votre compte Auth0 (p. ex. myaccount.auth0.com)
clientID
obligatoire
(String) Votre ID client Auth0
redirectUri
facultatif*
(String) La valeur redirectUri par défaut. La valeur par défaut est une chaîne vide (aucune). Si vous ne fournissez pas ici de valeur redirectUri globale, vous devrez fournir une valeur redirectUri pour chaque méthode utilisée.
scope
facultatif
(String) Le par défaut utilisé par l’application. L’utilisation de scopes peut vous permettre de renvoyer des claims précises pour certains champs de votre requête. Consultez notre documentation sur les scopes pour en savoir plus.
audience
facultatif
(String) L’audience par défaut à utiliser pour demander l’accès à l’API.
responseType
facultatif*
(String) La valeur responseType par défaut. Il peut s’agir de n’importe quelle liste de valeurs séparées par des espaces parmi code, token, id_token. La valeur par défaut est 'token', sauf si un redirectUri est fourni; dans ce cas, la valeur par défaut est 'code'. Si vous ne fournissez pas de valeur responseType globale, vous devrez fournir une valeur responseType pour chaque méthode utilisée.
responseMode
facultatif
(String) Cette option n’est pas définie par défaut. Elle peut être définie à 'form_post' pour envoyer le jeton ou le code à 'redirectUri' par POST. Les valeurs prises en charge sont query, fragment et form_post.
leeway
facultatif
(Integer) Une valeur en secondes; marge tolérée pour compenser le décalage d’horloge concernant les heures d’expiration de l’ID Token.
_disableDeprecationWarnings
facultatif
(Boolean) Désactive les avertissements de dépréciation; la valeur par défaut est false.
En raison du décalage d’horloge, il se peut que vous rencontriez parfois l’erreur The token was issued in the future. Le paramètre leeway permet d’ajouter quelques secondes de tolérance aux heures d’expiration de l’ID Token afin d’éviter cette situation.
Scope
La valeur scope par défaut dans auth0.js v9 est openid profile email.
Exécuter Auth0.js localement
Si vous ne précisez pas au minimum le scope ci-dessus lors de l’initialisation d’auth0.js et que votre site Web est exécuté depuis http://localhost ou http://127.0.0.1, l’appel à la méthode getSSOData() entraînera l’erreur suivante dans la console du navigateur :Consent required. When using getSSOData, the user has to be authenticated with the following scope: openid profile emailCela ne se produira pas si vous exécutez votre application en production ou si vous précisez le scope openid profile email. Pour en savoir plus, consultez le document Consentement de l’utilisateur et applications tierces.
La méthode authorize() peut être utilisée pour authentifier des utilisateurs au moyen de ou de connexions sociales, comme l’illustrent les exemples ci-dessous. Cette méthode appelle le point de terminaison /authorize de l’Authentication API et peut accepter divers paramètres au moyen de l’objet options.
Paramètre
Obligatoire
Description
audience
facultatif
(String) L’audience par défaut à utiliser pour demander l’accès à l’API.
connection
facultatif
(String) Spécifie la connexion à utiliser, au lieu de présenter toutes les connexions disponibles pour l’application.
scope
facultatif
(String) Les scopes pour lesquels vous souhaitez demander une autorisation. Ils doivent être séparés par un espace. Vous pouvez demander n’importe lequel des scopes OIDC standard concernant les utilisateurs, comme profile et email, des claims personnalisées qui doivent respecter un format avec espace de noms, ou tout scope pris en charge par l’API cible (par exemple, read:contacts). Incluez offline_access pour obtenir un .
responseType
facultatif
(String) Il peut s’agir de toute liste de valeurs code, token, id_token, séparées par des espaces. La valeur par défaut est 'token', sauf si un redirectUri est fourni, auquel cas la valeur par défaut est 'code'.
clientID
facultatif
(String) Votre ID client Auth0.
redirectUri
facultatif
(String) L’URL vers laquelle Auth0 redirigera le navigateur une fois l’autorisation accordée à l’utilisateur.
state
facultatif
(String) Une valeur arbitraire qui doit être conservée d’une redirection à l’autre. Elle est utile pour atténuer les attaques CSRF et pour toute information contextuelle (par exemple, une URL de retour) dont vous pourriez avoir besoin une fois le processus d’authentification terminé. Pour en savoir plus, consultez paramètre state. auth0.js, lorsqu’il est utilisé dans des applications monopages, gère automatiquement la génération et la validation de state si elle n’est pas spécifiée.
prompt
facultatif
(String) Une valeur de login forcera l’affichage de la page de connexion, peu importe la session en cours. Une valeur de none tentera d’ignorer les invites de connexion si une session existe déjà (consultez la documentation sur l’authentification silencieuse pour plus de détails).
Pour une connexion hébergée, il faut appeler la méthode /authorize().webAuth.authorize({//Toutes les options supplémentaires peuvent être ajoutées ici});Pour les connexions sociales, le paramètre connection devra être précisé :webAuth.authorize({connection: 'twitter'});
Pour l’authentification dans une fenêtre contextuelle, vous pouvez utiliser la méthode popup.authorize. L’authentification dans une fenêtre contextuelle ne peut pas être utilisée dans les pages de connexion hébergées. En général, l’authentification dans une fenêtre contextuelle est utilisée par les applications monopage afin de ne pas perdre l’état en cours lors d’une redirection de la page entière.Autorisation par défaut avec fenêtre contextuelle (Universal Login) :
webAuth.popup.authorize({ responseType: 'token' redirectUri: 'https://{yourApp}/popup_response_handler.html' //D'autres options peuvent être ajoutées ici}, function(err, authResult) { //faire quelque chose});
Et pour une connexion sociale dans une fenêtre contextuelle à l’aide de authorize :
Gestion des résultats de l’authentification par fenêtre contextuelle
Lorsque vous utilisez l’authentification par fenêtre contextuelle, vous devez fournir un redirectUri où la page de destination transmet les résultats de l’autorisation à la fonction de rappel à l’aide de la méthode webAuth.popup.callback. Une implémentation simple pourrait ressembler à ceci :
Un gestionnaire idéal ne devrait inclure que cette fonctionnalité minimale (c’est-à-dire éviter de recharger toute l’application uniquement pour traiter la réponse).Vous devrez ajouter le redirectUri à la liste Allowed Callback URLs de l’application, sur la page de configuration de l’application dans l’Auth0 Dashboard.
La connexion intégrée pour les applications Web utilise l’authentification inter-origines, sauf si vous configurez un domaine personnalisé pour votre locataire. L’authentification inter-origines utilise des témoins tiers pour permettre des transactions d’authentification sécurisées entre différentes origines.
La méthode login peut être utilisée pour la connexion intégrée au moyen de l’authentification inter-origines pour les connexions de base de données, à l’aide de /co/authenticate.
Paramètre
Obligatoire
Description
username
facultatif
(String) Le nom d’utilisateur à fournir pour l’authentification. L’un ou l’autre de username ou email doit être présent.
email
facultatif
(String) Le courriel à fournir pour l’authentification. L’un ou l’autre de username ou email doit être présent.
password
obligatoire
(String) Le mot de passe à fournir pour l’authentification.
realm
obligatoire
(String) Le nom de la connexion de base de données à utiliser pour l’authentification.
La méthode crossOriginVerification() peut être utilisée pour offrir une authentification inter-origines aux clients qui ont désactivé les témoins tiers dans leur navigateur. Pour en savoir plus sur son utilisation, consultez le document sur l’authentification inter-origines.
La méthode buildAuthorizeUrl permet de construire l’URL /authorize afin d’initialiser une nouvelle transaction. Utilisez cette méthode si vous souhaitez implémenter une authentification dans le navigateur (passive).Le paramètre state est une valeur opaque qu’Auth0 vous renverra. Cette méthode aide à prévenir les attaques CSRF et doit être spécifiée si vous redirigez vous-même vers l’URL au lieu d’appeler webAuth.authorize(). Pour en savoir plus, consultez le paramètre state.
Les applications qui utilisent une connexion intégrée doivent respecter deux critères pour bénéficier de l’ (SSO).
Les deux applications qui tentent d’utiliser le SSO doivent être des applications de première partie. Le SSO avec des applications tierces ne fonctionnera pas.
Elles doivent utiliser des domaines personnalisés, et les deux applications qui doivent utiliser le SSO ainsi que le locataire Auth0 doivent se trouver sur le même domaine. Traditionnellement, les domaines Auth0 suivent le format foo.auth0.com, mais les domaines personnalisés vous permettent d’utiliser le même domaine pour chacune des applications en question ainsi que pour votre locataire Auth0, ce qui réduit le risque d’attaques CSRF.
Nous recommandons d’utiliser Universal Login plutôt que de configurer le SSO dans des scénarios de connexion intégrée. Universal Login est la façon la plus fiable et la plus stable d’effectuer le SSO, et c’est la seule façon de le faire si vous devez utiliser plusieurs domaines pour vos applications, ou utiliser des applications tierces.
permet aux utilisateurs de se connecter en recevant un mot de passe à usage unique par courriel ou par message texte. Le processus vous oblige à démarrer le flux Passwordless, à générer et à envoyer un code à l’utilisateur (ou un lien contenant un code), puis à recueillir ses identifiants au moyen de la méthode de vérification. Cela peut prendre la forme d’un écran de connexion qui demande son courriel (ou son numéro de téléphone) ainsi que le code que vous venez de lui envoyer. Il est aussi possible d’utiliser un lien Passwordless au lieu d’envoyer un code à l’utilisateur. Il lui suffit alors de cliquer sur le lien dans son courriel ou son message texte pour appeler votre point de terminaison et vérifier automatiquement ces données à l’aide de la même méthode de vérification (sans que l’utilisateur ait à saisir manuellement un code).Pour utiliser Passwordless, vous devez initialiser auth0.js avec un redirectUri et définir responseType: 'token'.
La première étape de l’authentification Passwordless avec auth0.js consiste à utiliser la méthode passwordlessStart, qui accepte plusieurs paramètres dans son objet options :
Paramètre
Obligatoire
Description
connection
obligatoire
(String) Indique comment envoyer le code ou le lien à l’utilisateur. La valeur doit être email ou sms.
send
obligatoire
(String) La valeur doit être code ou link. Si elle est null, un lien sera envoyé.
phoneNumber
facultatif
(String) Le numéro de téléphone de l’utilisateur pour l’envoi d’un code ou d’un lien par SMS.
email
facultatif
(String) Le courriel de l’utilisateur pour l’envoi d’un code ou d’un lien par courriel.
Notez qu’exactement un des paramètres facultatifs phoneNumber et email doit être envoyé pour démarrer la transaction Passwordless.
webAuth.passwordlessStart({ connection: 'email', send: 'code', email: 'foo@bar.com' }, function (err,res) { // gérer les erreurs ou continuer });
Si vous envoyez un code, vous devrez ensuite demander à l’utilisateur de le saisir. Vous traiterez ensuite le code et authentifierez l’utilisateur à l’aide de la méthode passwordlessLogin, qui accepte plusieurs paramètres pouvant être transmis dans son objet options :
Paramètre
Obligatoire
Description
connection
requis
(String) Indique comment envoyer le code ou le lien à l’utilisateur. La valeur doit être email ou sms, et identique à celle transmise à passwordlessStart.
verificationCode
requis
(String) Le code envoyé à l’utilisateur, soit sous forme de code, soit intégré à un lien.
phoneNumber
facultatif
(String) Le numéro de téléphone de l’utilisateur auquel le code ou le lien a été envoyé par SMS.
email
facultatif
(String) Le courriel de l’utilisateur auquel le code ou le lien a été envoyé par courriel.
Comme avec passwordlessStart, un seul des paramètres facultatifs phoneNumber et email doit être transmis afin de vérifier la transaction Passwordless.Pour utiliser passwordlessLogin, vous devez préciser les options redirectUri et responseType lors de l’initialisation de WebAuth.
webAuth.passwordlessLogin({ connection: 'email', email: 'foo@bar.com', verificationCode: '389945' }, function (err,res) { // gérer les erreurs ou continuer });
Extraire authResult et obtenir les informations sur l’utilisateur
Après l’authentification, vous pouvez utiliser la méthode parseHash pour analyser un fragment de hachage d’URL lorsque l’utilisateur est redirigé vers votre application afin d’extraire le résultat d’une réponse d’authentification d’Auth0. Vous pouvez choisir de gérer cela dans une page de rappel qui redirigera ensuite vers votre application principale, ou directement dans la page, selon le contexte.La méthode parseHash prend un objet options qui contient les paramètres suivants :
Paramètre
Obligatoire
Description
state
facultatif
(String) Une valeur opaque que l’application ajoute à la demande initiale et qu’Auth0 inclut lors de la redirection vers l’application. Cette valeur est utilisée par auth0.js pour prévenir les attaques CSRF.
facultatif
(String) Utilisé pour vérifier l’ID Token
hash
facultatif
(String) Le hachage de l’URL (s’il n’est pas fourni, window.location.hash sera utilisé par défaut)
Le contenu de l’objet authResult renvoyé par parseHash dépend des paramètres d’authentification utilisés. Il peut inclure :
Élément
Description
accessToken
Un pour l’API, spécifié par audience
expiresIn
Une chaîne contenant la durée de validité (en secondes) du accessToken
idToken
Un JWT ID Token contenant des informations sur le profil de l’utilisateur
webAuth.parseHash({ hash: window.location.hash }, function(err, authResult) { if (err) { return console.log(err); } webAuth.client.userInfo(authResult.accessToken, function(err, user) { // Vous avez maintenant les informations de l'utilisateur });});
Comme indiqué ci-dessus, la méthode client.userInfo peut être appelée en lui transmettant l’accessToken renvoyé. Elle enverra une requête au point de terminaison /userinfo et retournera l’objet user, qui contient les renseignements sur l’utilisateur, présentés de façon semblable à l’exemple ci-dessous.
Vous pouvez maintenant utiliser ces renseignements selon les besoins de votre application, par exemple pour récupérer l’ensemble des informations de profil de l’utilisateur à l’aide de la , comme indiqué ci-dessous.
Par défaut (et si responseType contient id_token), auth0.js génère une valeur nonce aléatoire lorsque vous appelez webAuth.authorize, la stocke dans le stockage local, puis la récupère dans webAuth.parseHash. Ce comportement par défaut convient dans la plupart des cas, mais certains cas d’utilisation peuvent exiger qu’un développeur contrôle la valeur nonce.
Si vous souhaitez utiliser une valeur nonce générée par le développeur, vous devez la fournir comme option à la fois à webAuth.authorize et à webAuth.parseHash.
webAuth.authorize({<Tooltip tip="Nonce : nombre arbitraire émis une seule fois dans un protocole d’authentification pour détecter et prévenir les attaques par rejeu." cta="Voir le glossaire" href="/docs/glossary?term=nonce">nonce</Tooltip>: '1234', responseType: 'token id_token'}); webAuth.parseHash({nonce: '1234'}, callback);Si vous appelez webAuth.checkSession au lieu de webAuth.authorize, vous devez seulement spécifier votre valeur nonce personnalisée comme option de checkSession :
webAuth.checkSession({ nonce: '1234',}, function (err, authResult) { ...});
La méthode webAuth.checkSession vérifiera automatiquement que la revendication nonce du renvoyé correspond à la valeur fournie dans l’option.
Lorsque Auth0.js est utilisé pour la connexion intégrée, il utilise le point de terminaison /co/authenticate, qui peut produire les erreurs suivantes :
Les descriptions d’erreur sont destinées à être compréhensibles pour les humains. La description ne doit pas être interprétée par du code et peut être modifiée à tout moment.
Statut
Code
Description
400
invalid_request
Corps de requête invalide. Les paramètres requis sont, et doivent être uniquement, client_id, credential_type, username, otp et realm.
401
unauthorized_client
Connexion inter-origines non autorisée.
400
unsupported_credential_type
Paramètre de type d’identifiant inconnu.
400
invalid_request
Realm non-existent-connection inconnu.
403
access_denied
Courriel ou mot de passe incorrect.
403
access_denied
Erreur d’authentification
403
blocked_user
Utilisateur bloqué
401
password_leaked
Cette tentative de connexion a été bloquée parce que le mot de passe que vous utilisez a déjà été divulgué lors d’une fuite de données (pas dans cette application).
429
too_many_attempts
Votre compte a été bloqué après plusieurs tentatives de connexion consécutives. Nous vous avons envoyé une notification selon votre mode de contact préféré avec des instructions pour le débloquer.
429
too_many_attempts
Nous avons détecté un comportement de connexion suspect et toute tentative supplémentaire sera bloquée. Veuillez communiquer avec l’administrateur.
De plus, vous pouvez aussi recevoir une erreur 403 générique sans propriété error ni error_description. Le corps de la réponse contiendrait simplement quelque chose de semblable à ce qui suit :
Origin https://test.app is not allowed.
Pour déconnecter un utilisateur, utilisez la méthode logout(). Cette méthode accepte un objet d’options pouvant inclure les paramètres suivants.Si le paramètre clientID est inclus, l’URL returnTo fournie doit figurer dans les Allowed Logout URLs de l’application dans l’Auth0 Dashboard. Toutefois, si le paramètre clientID n’est pas inclus, l’URL returnTo doit figurer dans les Allowed Logout URLs au niveau du compte dans l’Auth0 Dashboard.
webAuth.logout({ returnTo: 'some url here', clientID: 'some client ID here'});
Pour inscrire un utilisateur, utilisez la méthode signup. Cette méthode accepte un objet d’options qui peut inclure les paramètres suivants.
Paramètre
Obligatoire
Description
email
obligatoire
(String) Adresse de courriel de l’utilisateur
password
obligatoire
(String) Mot de passe souhaité par l’utilisateur
username
obligatoire*
(String) Nom d’utilisateur souhaité. *Obligatoire si vous utilisez une connexion de base de données et que Requires Username est activé
connection
obligatoire
(String) Nom de la connexion de base de données de votre application à utiliser pour tenter de créer le compte utilisateur
user_metadata
facultatif
(JSON object) Attributs supplémentaires utilisés pour les renseignements sur l’utilisateur. Ils seront stockés dans user_metadata
Les inscriptions doivent être effectuées pour des connexions de base de données. Voici un exemple de la méthode signup et un exemple de code pour un formulaire.
Utiliser checkSession pour obtenir de nouveaux jetons
La méthode checkSession vous permet d’obtenir un nouveau jeton d’Auth0 pour un utilisateur déjà authentifié auprès d’Auth0 sur votre domaine. La méthode accepte tous les paramètres OAuth2 valides qui seraient normalement envoyés à authorize. Si vous les omettez, elle utilisera ceux fournis lors de l’initialisation d’Auth0.L’appel à checkSession peut servir à obtenir un nouveau jeton pour l’API spécifiée comme lors de l’initialisation de webAuth :
webAuth.checkSession({}, function (err, authResult) { // err si le parseHash automatique échoue ...});
Consultez Extraire AuthResult et obtenir les renseignements de l’utilisateur pour connaître le format de authResult.Ou bien, le jeton peut être obtenu pour une API différente de celle utilisée lors de l’initialisation de webAuth en précisant une audience et un scope :
webAuth.checkSession( { audience: `https://mydomain/another-api/˜`, scope: 'read:messages' }, function (err, authResult) { // erreur si le parseHash automatique échoue ...});
Notez que checkSession() déclenche toutes les Rules que vous avez éventuellement configurées. Vous devriez donc vérifier vos Rules dans l’Auth0 Dashboard avant de l’utiliser.La redirection réelle vers /authorize se fait dans une iframe; votre application ne sera donc pas rechargée et vous ne serez pas redirigé hors de celle-ci.Cependant, le navigateur doit avoir les témoins tiers activés. Sinon, checkSession() ne pourra pas accéder à la session de l’utilisateur actuel (ce qui rend impossible l’obtention d’un nouveau jeton sans rien afficher à l’utilisateur). Il en ira de même si les utilisateurs ont la fonctionnalité ITP de Safari activée.N’oubliez pas d’ajouter l’URL d’où provient la demande d’autorisation à la liste Origines Web autorisées de votre application Auth0 dans l’Auth0 Dashboard, sous les Settings de votre application.
Si la connexion est une connexion sociale et que vous utilisez les clés de développement Auth0, l’appel à checkSession renverra toujours login_required.
Dans certains scénarios impliquant plusieurs applications, où une déconnexion unique est souhaitée (lorsqu’un utilisateur se déconnecte d’une application, il doit aussi être déconnecté des autres applications), une application peut être configurée pour interroger périodiquement Auth0 à l’aide de checkSession() afin de vérifier si une session existe. Si aucune session n’existe, vous pouvez alors déconnecter l’utilisateur de l’application. La même méthode de vérification périodique peut être utilisée pour mettre en œuvre l’authentification silencieuse dans un scénario d’authentification unique (SSO).L’intervalle entre les appels à checkSession() doit être d’au moins 15 minutes afin d’éviter tout problème futur lié à la limitation du nombre de requêtes pour cet appel.
Si vous essayez de mettre en place une fonctionnalité de réinitialisation du mot de passe, utilisez la méthode changePassword et transmettez-lui un objet options contenant un paramètre connection et un paramètre email.
La Management API offre des fonctionnalités qui vous permettent d’associer et de dissocier des comptes utilisateur distincts provenant de différents fournisseurs, ainsi que de mettre à jour les métadonnées utilisateur. Pour en savoir plus, consultez la documentation sur la liaison des comptes utilisateur.Pour commencer, vous devez d’abord obtenir un qui peut être utilisé pour appeler la Management API. Pour ce faire, indiquez l’audience https://{yourDomain}/api/v2/ lors de l’initialisation d’auth0.js; vous obtiendrez alors le jeton d’accès dans le cadre du flux d’authentification.Si vous utilisez des domaines personnalisés, vous devrez créer une nouvelle instance de webAuth en utilisant votre domaine Auth0 plutôt que votre domaine personnalisé pour les appels à la Management API, car elle fonctionne uniquement avec les domaines Auth0.Vous pouvez également le faire à l’aide de checkSession() :Vous devez préciser les scopes dont vous avez besoin. 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
Une fois le jeton d’accès obtenu, vous pouvez créer une nouvelle instance auth0.Management en lui transmettant le Domaine Auth0 du compte ainsi que le jeton d’accès.
Pour obtenir les données du profil de l’utilisateur, utilisez la méthode getUser() en lui passant userId et un callback en paramètres. La méthode renvoie le profil de l’utilisateur. Notez que le userID requis ici est le même que celui récupéré par la méthode client.userInfo.
auth0Manage.getUser(userId, cb);
Lorsque vous mettez à jour les métadonnées utilisateur, vous devez d’abord créer un objet userMetadata, puis appeler la méthode patchUserMetadata en lui passant l’id de l’utilisateur et l’objet userMetadata que vous avez créé. Les valeurs de cet objet remplaceront les valeurs existantes ayant la même clé ou ajouteront de nouvelles valeurs pour les clés qui n’existent pas encore dans les métadonnées utilisateur. Pour en savoir plus, consultez Metadata.
auth0Manage.patchUserMetadata(userId, userMetadata, cb);
La liaison de comptes utilisateur permet à un utilisateur de s’authentifier à partir de n’importe lequel de ses comptes et, peu importe celui qu’il utilise, d’accéder au même profil à la connexion. Par défaut, Auth0 traite tous ces comptes comme des profils distincts. Si vous voulez lier les comptes d’un utilisateur, utilisez cette méthode.La méthode linkUser accepte deux paramètres : le userId principal et l’ID Token de l’utilisateur secondaire (le jeton obtenu après la connexion avec cette identité). L’ID utilisateur en question est l’identifiant unique du compte utilisateur principal. L’ID doit être transmis avec le préfixe du fournisseur, par exemple auth0|1234567890 ou facebook|1234567890, lorsque vous utilisez cette méthode. Consultez User Account Linking pour en savoir plus.
auth0Manage.linkUser(userId, secondaryUserToken, cb);Après la liaison des comptes, le second compte n’existera plus comme entrée distincte dans la base de données des utilisateurs et ne sera accessible qu’à titre de partie du compte principal.
Lorsque des comptes sont liés, les métadonnées du compte secondaire ne sont pas fusionnées avec celles du compte principal et, s’ils sont ensuite dissociés, le compte secondaire ne conservera pas non plus les métadonnées du compte principal lorsqu’il redeviendra distinct.
Authenticate
Manage Users
Customize
Auth0 AI
Platform