Auth0.js

Comment installer, initialiser et utiliser Auth0.js

La bibliothèque Auth0.js est une bibliothèque Javascript côté client pour Auth0. Elle prend en charge les cas d’utilisation de connexion hébergée et connexion intégrée. Cet article porte sur la v10, la version actuelle.

Consultez la documentation API complète de la bibliothèque.

Migrer de v9 à v10

Auth0.js v10 contient un correctif de sécurité pour CVE-2026-42280 et un changement incompatible :

Élément touché	Détails
Applications utilisant RS256	Aucun changement incompatible
Applications utilisant HS256	parseHash() renvoie maintenant une erreur invalid_token au lieu de réussir sans signaler d’erreur. Passez à RS256 dans Auth0 Dashboard : Applications > votre application > Settings > Advanced Settings > OAuth > Algorithme de signature JsonWebToken > RS256

Si vous avez besoin de la référence de l’API v9, consultez le package auth0-js sur npm et sélectionnez votre version v9, ou parcourez le code source et le journal des modifications de la v9 sur GitHub.

La connexion intégrée pour les applications Web utilise l’authentification inter-origines, sauf si vous configurez un domaine personnalisé pour votre tenant. L’authentification inter-origines utilise des cookies tiers pour permettre des transactions d’authentification sécurisées entre différentes origines.

Exemple prêt à l’emploi

Le répertoire d’exemple 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 :

1. Si node n’est pas installé, faites-le maintenant
2. Installez les dépendances en exécutant npm install à partir de la racine de ce projet
3. Enfin, exécutez npm start à partir de la racine de ce projet, puis ouvrez dans votre navigateur l’application qui s’exécute sur le serveur node, probablement à l’adresse http://localhost:3000/example.

Configuration et initialisation

Les sections suivantes portent sur les méthodes d’installation, comment initialiser Auth0.js, l’inscription, la connexion, la déconnexion et plus encore.

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 utilise des appels entre origines dans des iframes masquées pour effectuer l’authentification. Pour que cela puisse se faire de façon sécuritaire, Auth0 doit connaître les domaines où vous hébergez vos applications.

Ajoutez le domaine au champ Allowed Web Origins. Vous trouverez ce champ dans la section Paramètres de l’application de votre Dashboard.

Options d’installation

Vous avez plusieurs façons d’utiliser Auth0.js dans votre projet. Choisissez celle qui convient le mieux à vos besoins :

Installez-le avec npm ou yarn :

npm install auth0-js

yarn add auth0-js

Après avoir installé le module auth0-js, regroupez-le avec toutes ses dépendances, ou importez-le ainsi :

import auth0 from 'auth0-js';

Vous pouvez aussi inclure le script via le CDN :

<script src="https://cdn.auth0.com/js/auth0/10.0.0/auth0.min.js"></script>

Initialisation

Initialisez une nouvelle instance de l’application Auth0 comme suit :

Paramètres disponibles

Il y a deux paramètres obligatoires à transmettre dans l’objet options lors de l’instanciation de webAuth, ainsi que d’autres paramètres 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) Le redirectUri utilisé par défaut. La valeur par défaut est une chaîne vide (aucun). Si vous ne fournissez pas ici de valeur globale pour redirectUri, vous devrez fournir une valeur redirectUri pour chaque méthode utilisée.
scope	facultatif	(String) Le scope(s) par défaut utilisé par l’application. L’utilisation de scopes peut vous permettre de retourner des claims précis 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) Le responseType utilisé 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, auquel cas la valeur par défaut est 'code'. Si vous ne fournissez pas de valeur globale pour responseType, vous devrez fournir une valeur responseType pour chaque méthode utilisée.
responseMode	facultatif	(String) Cette option est omise par défaut. Elle peut être définie à 'form_post' afin d’envoyer le token ou le code au 'redirectUri' par POST. Les valeurs prises en charge sont query, fragment et form_post.
leeway	facultatif	(Integer) Une valeur en secondes : marge de tolérance pour tenir compte du décalage d’horloge concernant les délais d’expiration du ID Token.
_disableDeprecationWarnings	facultatif	(Boolean) Désactive les avertissements de dépréciation; la valeur par défaut est false.

En raison de décalages d’horloge, vous pourriez parfois rencontrer l’erreur The token was issued in the future. Le paramètre leeway peut être utilisé pour accorder quelques secondes de tolérance aux délais d’expiration du ID Token, afin d’éviter cette situation.

Scope

La valeur scope par défaut dans Auth0.js v10 est openid profile email.

Exécuter Auth0.js en local

Si vous ne précisez pas au minimum le scope ci-dessus lors de l’initialisation d’Auth0.js et que votre site Web s’exécute à partir de http://localhost ou de http://127.0.0.1, l’appel de 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 email

Cela 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.

Connexion

Vous pouvez choisir une méthode de connexion selon le type d’authentification requis dans votre application.

webAuth.authorize()

La méthode authorize() peut être utilisée pour connecter des utilisateurs au moyen de Universal Login ou de connexions sociales, comme le montrent les exemples ci-dessous. Cette méthode appelle le point de terminaison /authorize de l’Authentication API et peut accepter divers paramètres par l’intermédiaire de l’objet options.

Paramètre	Obligatoire	Description
audience	facultatif	(chaîne) L’audience par défaut à utiliser pour demander l’accès à l’API.
connection	facultatif	(chaîne) Spécifie la connexion à utiliser au lieu de présenter toutes les connexions offertes à l’application.
scope	facultatif	(chaîne) Les scopes pour lesquels vous voulez demander une autorisation. Ils doivent être séparés par un espace. Vous pouvez demander n’importe lequel des scopes OIDC standard liés aux utilisateurs, comme profile et email, des claims personnalisés 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 Refresh Token.
responseType	facultatif	(chaîne) Peut être une 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, auquel cas la valeur par défaut est 'code'.
clientID	facultatif	(chaîne) Votre ID client Auth0.
redirectUri	facultatif	(chaîne) L’URL vers laquelle Auth0 redirigera le navigateur une fois l’autorisation accordée à l’utilisateur.
state	facultatif	(chaîne) 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 l’état s’il n’est pas précisé.
prompt	facultatif	(chaîne) La valeur login forcera l’affichage de la page de connexion, peu importe la session en cours. La valeur none tentera d’éviter d’afficher les écrans de connexion si une session existe déjà (consultez la documentation sur l’authentification silencieuse pour plus de détails).

Pour la connexion hébergée, il faut appeler la méthode /authorize().

webAuth.authorize({//Toute option supplémentaire peut être ajoutée ici});

Pour les connexions sociales, le paramètre connection devra être précisé :

webAuth.authorize({connection: 'twitter'});

webAuth.popup.authorize()

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 d’éviter de perdre l’état courant lors d’une redirection qui recharge entièrement la page.

Autorisation par défaut avec fenêtre contextuelle (Universal Login) :

webAuth.popup.authorize({
  responseType: 'token'
  redirectUri: 'https://YOUR_APP/popup_response_handler.html'
  //D'autres options peuvent être ajoutées ici
}, function(err, authResult) {
  //faire quelque chose
});

Et pour la connexion sociale au moyen d’une fenêtre contextuelle avec authorize :

webAuth.popup.authorize({
  responseType: 'token'
  redirectUri: 'https://{yourApp}/popup_response_handler.html',
  connection: 'twitter'
}, function(err, authResult) {
  //faire quelque chose
});

Gérer les résultats de l’authentification dans une fenêtre contextuelle

Lorsque vous utilisez l’authentification dans une fenêtre contextuelle, vous devez fournir un redirectUri où la page de destination transmet les résultats de l’autorisation au callback à l’aide de la méthode webAuth.popup.callback. Une mise en œuvre simple pourrait ressembler à ceci :

<!-- popup_response_handler.html -->
<html>
  <body>
    <script src="https://cdn.auth0.com/js/auth0/10.0.0/auth0.min.js"></script>
    <script type="text/javascript">
      var webAuth = new auth0.WebAuth({
        domain:       'YOUR_DOMAIN',
        clientID:     'YOUR_CLIENT_ID'
      });
      webAuth.popup.callback();
    </script>
  </body>
</html>

Un handler idéal ne devrait contenir que le strict minimum (c’est-à-dire sans recharger toute l’application simplement 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 le Dashboard.

webAuth.login()

La connexion intégrée pour les applications web utilise l’authentification inter-origines, à moins que vous ne configuriez un domaine personnalisé pour votre tenant. L’authentification inter-origines utilise des cookies 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 par authentification inter-origines avec des connexions de base de données, au moyen 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) L’adresse 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.

webAuth.login({
  realm: 'tests',
  username: 'testuser',
  password: 'testpass',
});

webAuth.crossOriginVerification()

La méthode crossOriginVerification() peut servir à offrir une authentification inter-origines aux clients qui ont désactivé les cookies tiers dans leur navigateur. Pour en savoir plus sur son utilisation, consultez Authentification inter-origines.

buildAuthorizeUrl(options)

La méthode buildAuthorizeUrl peut être utilisée pour générer l’URL /authorize afin d’initialiser une nouvelle transaction. Utilisez cette méthode si vous souhaitez mettre en place une authentification passive dans le navigateur.

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 effectuez vous-même la redirection vers l’URL au lieu d’appeler webAuth.authorize(). Pour en savoir plus, consultez State Parameter.

Authentification unique avec authentification intégrée

La connexion intégrée permet l’authentification unique (SSO) lorsque vos applications partagent l’architecture suivante :

1. Les applications qui tentent d’utiliser le SSO sont des applications propriétaires. Le partage de sessions de connexion intégrée avec des applications tierces n’est pas pris en charge.
2. Les applications et votre tenant Auth0 partagent un domaine de premier niveau grâce à un domaine personnalisé. Les domaines Auth0 traditionnels utilisent le format foo.auth0.com; les domaines personnalisés permettent à vos applications et à votre tenant Auth0 de partager le même domaine de premier niveau, ce qui aide aussi à prévenir les attaques CSRF.

Lorsque votre architecture répond à ces critères, le SSO intégré avec Auth0.js convient bien. Universal Login gère automatiquement le SSO entre plusieurs domaines ou avec des applications tierces grâce à sa couche de session, et les deux peuvent coexister dans la même application — par exemple, Universal Login pour la connexion principale et Auth0.js pour l’inscription intégrée d’un facteur ou les flux de step-up. Pour comparer les avantages et les inconvénients, consultez Hosted Login vs. Embedded Login.

Connexion sans mot de passe

sans mot de passe permet aux utilisateurs de se connecter en recevant un mot de passe à usage unique par courriel ou par message texte. Le processus exige d’amorcer le flux sans mot de passe, de générer et d’acheminer un code à l’utilisateur (ou un code dans un lien), puis de 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 adresse courriel (ou son numéro de téléphone) ainsi que le code que vous venez de lui envoyer. Cela peut aussi être mis en œuvre sous la forme d’un lien sans mot de passe plutôt que d’un code envoyé à l’utilisateur. Il lui suffit alors de cliquer sur le lien dans son courriel ou son message texte pour atteindre votre point de terminaison et faire 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 l’authentification sans mot de passe, initialisez Auth0.js avec un redirectUri et définissez responseType: 'token'.

Démarrer l’authentification sans mot de passe

La première étape de l’authentification sans mot de passe avec Auth0.js est la méthode passwordlessStart, qui comporte plusieurs paramètres pouvant être transmis 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 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) L’adresse courriel de l’utilisateur pour l’envoi d’un code ou d’un lien par courriel.

Notez qu’un seul des paramètres facultatifs phoneNumber et email doit être envoyé pour démarrer la transaction sans mot de passe.

webAuth.passwordlessStart({
    connection: 'email',
    send: 'code',
    email: '[e-mail]'
  }, function (err,res) {
    // gérer les erreurs ou continuer
  }
);

Finaliser l’authentification sans mot de passe

Si vous envoyez un code, vous devrez ensuite demander à l’utilisateur de le saisir. Vous traiterez ce code et authentifierez l’utilisateur à l’aide de la méthode passwordlessLogin, qui comporte plusieurs paramètres pouvant être transmis 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, et correspondre à celle transmise à passwordlessStart.
verificationCode	obligatoire	(String) Le code envoyé à l’utilisateur, soit comme code, soit intégré dans 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) L’adresse courriel de l’utilisateur à laquelle 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 sans mot de passe.

Pour utiliser passwordlessLogin, précisez redirectUri et responseType lors de l’initialisation de WebAuth.

webAuth.passwordlessLogin({
    connection: 'email',
    email: '[e-mail]',
    verificationCode: '389945'
  }, function (err,res) {
    // gérer les erreurs ou continuer
  }
);

Extraire le authResult et obtenir des renseignements sur l’utilisateur

Après l’authentication, vous pouvez utiliser la méthode parseHash pour analyser le fragment de hachage d’une URL lorsque l’utilisateur est redirigé vers votre application afin d’extraire le résultat d’une Authentication response Auth0. Vous pouvez choisir de gérer cela dans une page de callback, qui redirigera ensuite vers votre application principale, ou directement dans la page, selon la situation.

La méthode parseHash prend un objet options qui contient les paramètres suivants :

Parameter	Required	Description
state	optional	(String) Une valeur opaque que l’application ajoute à la requête 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.
nonce	optional	(String) Utilisé pour vérifier le ID Token
hash	optional	(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’authentication utilisés. Il peut inclure :

Item	Description
accessToken	Un jeton d’accès pour l’API spécifiée par audience
expiresIn	Une chaîne contenant la durée de validité (en secondes) du accessToken
idToken	Un JWT ID Token contenant des renseignements du profil 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 passant l’accessToken renvoyé. Elle enverra une requête au point de terminaison /userinfo et renverra l’objet user, qui contient les renseignements de l’utilisateur, dans un format semblable à l’exemple ci-dessous.

{
    "sub": "auth0|123456789012345678901234",
    "nickname": "johnfoo",
    "name": "[e-mail]",
    "picture": "https://gravatar.com/avatar/example.png",
    "updated_at": "2018-05-07T14:16:52.013Z",
    "email": "[e-mail]",
    "email_verified": "false"
}

Vous pouvez maintenant utiliser ces renseignements autrement, selon les besoins de votre application, par exemple pour obtenir l’ensemble des données du profil de l’utilisateur au moyen de la Management API, comme décrit ci-dessous.

Utilisation des nonces

Par défaut (et si responseType contient id_token), Auth0.js génère un nonce aléatoire lorsque vous appelez webAuth.authorize, le stocke dans le stockage local, puis le récupère dans webAuth.parseHash. Ce comportement par défaut devrait convenir dans la plupart des cas, mais certains cas d’utilisation peuvent exiger qu’un développeur gère le nonce. Si vous souhaitez utiliser un nonce généré par le développeur, vous devez le fournir comme option à la fois à webAuth.authorize et à webAuth.parseHash.

webAuth.authorize({nonce: '1234', responseType: 'token id_token'});
webAuth.parseHash({nonce: '1234'}, callback);

Si vous appelez webAuth.checkSession au lieu de webAuth.authorize, vous n’avez qu’à indiquer votre nonce personnalisé comme option à checkSession :

webAuth.checkSession({
  nonce: '1234',
}, function (err, authResult) {
    ...
});

La méthode webAuth.checkSession vérifiera automatiquement que le claim nonce du ID Token renvoyé est le même que celui de l’option.

Codes d’erreur et descriptions

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 lues par des humains. La description ne doit pas être analysée par du code et peut être modifiée à tout moment.

Statut	Code	Description
400	invalid_request	Corps de la requête invalide. Les paramètres client_id, credential_type, username, otp et realm sont tous requis, et aucun autre n’est accepté.
401	unauthorized_client	La connexion interorigine n’est pas autorisée.
400	unsupported_credential_type	Paramètre credential_type 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, car le mot de passe que vous utilisez a déjà été divulgué lors d’une atteinte à la sécurité des 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 par votre méthode de contact préférée avec des instructions pour le débloquer.
429	too_many_attempts	Nous avons détecté un comportement de connexion suspect et les prochaines tentatives seront bloquées. Veuillez communiquer avec l’administrateur.

De plus, il est aussi possible d’obtenir 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.

Logout

Pour déconnecter un utilisateur, utilisez la méthode logout(). Cette méthode accepte un objet options, qui peut 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 le Dashboard Auth0. 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 le Dashboard Auth0.

webAuth.logout({
  returnTo: 'some url here',
  clientID: 'some client ID here'
});

Inscription

Pour inscrire un utilisateur, utilisez la méthode signup. Cette méthode accepte un objet options, qui peut inclure les paramètres suivants.

Paramètre	Obligatoire	Description
email	obligatoire	(String) Adresse courriel de l’utilisateur
password	obligatoire	(String) Mot de passe choisi par l’utilisateur
username	obligatoire*	(String) Nom d’utilisateur choisi par l’utilisateur. *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 dans laquelle tenter la création du compte d’utilisateur
user_metadata	facultatif	(objet JSON) Attributs supplémentaires servant à stocker des renseignements sur l’utilisateur. Sera stocké dans user_metadata

Les inscriptions doivent se faire au moyen de connexions de base de données. Voici un exemple de la méthode signup et un exemple de code pour un formulaire.

<h2>Signup Database Connection</h2>
<input class="signup-email" />
<input type="password" class="signup-password" />
<input type="button" class="signup-db" value="Signup!" />
<script type="text/javascript">
    $('.signup-db').click(function (e) {
        e.preventDefault();
        webAuth.signup({
            connection: 'Username-Password-Authentication',
            email: $('.signup-email').val(),
            password: $('.signup-password').val(),
            user_metadata: { plan: 'silver', team_id: 'a111' }
        }, function (err) {
            if (err) return alert('Something went wrong: ' + err.message);
            return alert('success signup without login!')
        });
    });
</script>

Utilisation de 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 pour votre domaine. Cette 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 définie comme audience lors de l’initialisation de webAuth :

webAuth.checkSession({}, function (err, authResult) {
  // err si parseHash automatique échoue
  ...
});

Consultez Extraire l’AuthResult et obtenir les renseignements de l’utilisateur pour connaître le format de authResult.

Sinon, il est possible d’obtenir le jeton pour une API différente de celle utilisée lors de l’initialisation de webAuth en précisant audience et scope :

webAuth.checkSession(
  {
    audience: `https://mydomain/another-api/˜`,
    scope: 'read:messages'
  }, function (err, authResult) {
  // err si le parseHash automatique échoue
  ...
});

Notez que checkSession() déclenche toutes les rules que vous avez peut-être configurées; vous devriez donc vérifier vos rules dans le Dashboard avant de l’utiliser.

La redirection vers /authorize s’effectue en fait à l’intérieur d’un iframe; votre application ne sera donc pas rechargée et ne sera pas redirigée ailleurs.

Cependant, le navigateur doit avoir les cookies tiers activés. Sinon, checkSession() ne peut pas accéder à la session de l’utilisateur actuel (ce qui rend impossible l’obtention d’un nouveau token sans rien afficher à l’utilisateur). La même chose se produira si les utilisateurs ont ITP de Safari activé.

N’oubliez pas d’ajouter l’URL d’origine de la requête d’autorisation à la liste Allowed Web Origins de votre application Auth0 dans le Dashboard, sous les Settings de votre application.

Si la connection est une connexion sociale et que vous utilisez les clés de développement Auth0, la requête checkSession retournera toujours login_required.

Vérification périodique avec checkSession()

Dans certains scénarios comportant plusieurs applications, où la 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 vérifications effectuées avec checkSession() devrait être d’au moins 15 minutes entre les appels, afin d’éviter tout problème futur lié à la limitation du débit de cet appel.

Requêtes de réinitialisation du mot de passe

Si vous souhaitez mettre en place une fonctionnalité de réinitialisation du mot de passe, vous utiliserez la méthode changePassword et lui passerez un objet options comprenant un paramètre connection et un paramètre email.

$('.change_password').click(function () {
    webAuth.changePassword({
      connection: 'db-conn',
      email:   '[e-mail]'
    }, function (err, resp) {
      if(err){
        console.log(err.message);
      }else{
        console.log(resp);
      }
    });
  });

L’utilisateur reçoit un courriel contenant un lien pour réinitialiser son mot de passe.

Gestion des utilisateurs

La Management API fournit des fonctionnalités qui vous permettent de lier et de dissocier des comptes d’utilisateur distincts provenant de différents fournisseurs, ainsi que de mettre à jour les métadonnées de l’utilisateur. Pour en savoir plus, consultez Liaison de comptes d’utilisateur.

Pour commencer, vous devez d’abord obtenir un jeton d’accès qui peut être utilisé pour appeler la Management API. Vous pouvez le faire en précisant l’audience https://{yourDomain}/api/v2/ lors de l’initialisation d’Auth0.js; dans ce cas, vous obtiendrez le jeton d’accès dans le cadre du flux d’authentification.

Si vous utilisez des domaines personnalisés, vous devrez instancier une nouvelle instance de webAuth en utilisant votre domaine Auth0 plutôt que votre domaine personnalisé afin de l’utiliser pour les appels à la Management API, car celle-ci fonctionne uniquement avec des domaines Auth0.

Vous pouvez aussi le faire avec checkSession() :

Vous devez préciser les scopes exacts 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 que vous avez le jeton d’accès, vous pouvez créer une instance auth0.Management en lui passant le domaine Auth0 du compte ainsi que le jeton d’accès.

Obtenir le profil de l’utilisateur

Pour obtenir les données du profil de l’utilisateur, utilisez la méthode getUser() avec userId et un callback comme 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é à partir de la méthode client.userInfo. auth0Manage.getUser(userId, cb);

Mettre à jour le profil d’utilisateur

Pour mettre à jour les métadonnées de l’utilisateur, vous devez d’abord créer un objet userMetadata, puis appeler la méthode patchUserMetadata en lui transmettant l’ID utilisateur et l’objet userMetadata que vous avez créé. Les valeurs de cet objet remplaceront les valeurs existantes associées à la même clé, ou en ajouteront de nouvelles si elles n’existent pas encore dans les métadonnées de l’utilisateur. Pour en savoir plus, consultez Métadonnées. auth0Manage.patchUserMetadata(userId, userMetadata, cb);

Lier des utilisateurs

La liaison de comptes d’utilisateur permet à un utilisateur de s’authentifier avec n’importe lequel de ses comptes et, peu importe celui utilisé, d’accéder au même profil à la connexion. Par défaut, Auth0 traite tous ces comptes comme des profils distincts. Donc, si vous voulez que les comptes d’un utilisateur soient liés, c’est la façon de procéder.

La méthode linkUser accepte deux paramètres : le userId principal et l’ID Token de l’utilisateur secondaire (le token obtenu après la connexion avec cette identité). L’ID utilisateur en question est l’identifiant unique du compte d’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 Liaison de comptes d’utilisateur pour plus de détails. auth0Manage.linkUser(userId, secondaryUserToken, cb);

Après la liaison des comptes, le deuxième compte n’existera plus comme entrée distincte dans la base de données des utilisateurs et ne sera accessible qu’en tant que 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. 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.