Rediriger les utilisateurs à partir de Rules

Découvrez comment personnaliser les flux d’authentification en redirigeant les utilisateurs à l’aide de Rules. Les éléments personnalisables comprennent notamment la MFA, l’acceptation de la politique de confidentialité et la collecte de données utilisateur.

La date de fin de vie (EOL) de Rules et Hooks sera le 18 novembre 2026, et ils ne sont plus offerts aux nouveaux locataires créés à compter du 16 octobre 2023. Les locataires existants ayant des Hooks actifs conserveront l’accès au produit Hooks jusqu’à sa fin de vie.

Nous vous recommandons fortement d’utiliser Actions pour étendre les fonctionnalités d’Auth0. Avec Actions, vous avez accès à des informations de typage détaillées, à une documentation intégrée et à des packages npm publics, et vous pouvez connecter des intégrations externes qui enrichissent votre expérience globale d’extensibilité. Pour en savoir plus sur ce qu’offre Actions, consultez Comprendre le fonctionnement des Auth0 Actions.

Pour vous aider dans votre migration, nous proposons des guides pour migrer de Rules vers Actions et migrer de Hooks vers Actions. Nous avons également une page dédiée, Passer à Actions, qui présente des comparaisons de fonctionnalités, une démonstration d’Actions et d’autres ressources pour vous accompagner dans votre migration.

Pour en savoir plus sur la dépréciation de Rules et Hooks, consultez notre billet de blogue : Preparing for Rules and Hooks End of Life.

Vous pouvez utiliser les Auth0 Rules pour rediriger les utilisateurs avant qu’une transaction d’authentification soit terminée. Cela vous permet de mettre en œuvre des flux d’authentification personnalisés qui nécessitent une interaction utilisateur supplémentaire au-delà du formulaire de connexion standard. Les règles de redirection sont couramment utilisées pour mettre en place une authentification multifacteur (MFA) personnalisée dans Auth0, mais elles peuvent aussi être utilisées pour :

• Faire accepter de façon personnalisée la politique de confidentialité, les conditions d’utilisation et les formulaires de divulgation des données.
• Recueillir de façon sécurisée, une seule fois, des données de profil supplémentaires requises.
• Permettre aux utilisateurs distants d’Active Directory de modifier leur mot de passe.
• Exiger des utilisateurs qu’ils fournissent une vérification supplémentaire lorsqu’ils se connectent à partir d’emplacements inconnus.
• Recueillir davantage de renseignements sur vos utilisateurs que ceux qu’ils ont fournis lors de leur inscription initiale.

Vous pouvez rediriger un utilisateur une seule fois par flux d’authentification. Si vous avez une règle qui redirige un utilisateur, vous ne pouvez pas invoquer une deuxième règle pour rediriger l’utilisateur plus tard.

Pour en savoir plus, consultez Multi-Factor Authentication in Auth0.

​

Lancer la redirection et reprendre l’authentification

Définissez la propriété context.redirect comme suit :

function (user, context, callback) {
  context.redirect = {
    url: "https://example.com/foo"
  };
  return callback(null, user, context);
}

Une fois que toutes les Rules ont terminé leur exécution, Auth0 redirige l’utilisateur vers l’URL indiquée dans la propriété context.redirect.url. Auth0 transmet également un paramètre state dans cette URL. Par exemple :

https://example.com/foo?state=abc123

Votre URL de redirection doit extraire le paramètre state et le renvoyer à Auth0 pour reprendre la transaction d’authentification. Le paramètre state est une valeur opaque utilisée pour prévenir les attaques de falsification de requête intersites (CSRF).

Après la redirection, reprenez l’authentification en redirigeant l’utilisateur vers le point de terminaison /continue et en incluant dans l’URL le paramètre state reçu. Si vous ne renvoyez pas le paramètre state d’origine au point de terminaison /continue, Auth0 perdra le contexte de la transaction de connexion et l’utilisateur ne pourra pas se connecter en raison d’une erreur invalid_request.

Par exemple :

Si vous utilisez un domaine personnalisé :

https://{yourAuth0CustomDomain}/continue?state={originalState}

THE_ORIGINAL_STATE est la valeur qu’Auth0 a générée et transmise à l’URL de redirection. Par exemple, si votre Rule a redirigé vers https://example.com/foo, Auth0 utiliserait une URL de redirection semblable à https://example.com/foo?state=abc123. Ainsi, abc123 correspondrait à THE_ORIGINAL_STATE. Pour reprendre la transaction d’authentification, vous redirigeriez vers :

Lorsqu’un utilisateur a été redirigé vers le point de terminaison /continue :

• toutes les Rules seront exécutées à nouveau; toutefois, context.redirect sera ignoré afin de permettre à l’authentification de se poursuivre.
• toute modification apportée à l’objet user est effectuée pendant la redirection, avant l’appel au point de terminaison /continue. Par exemple, les mises à jour effectuées au moyen de l’Auth0 Management API sont disponibles une fois la transaction reprise.

​

Valider une reprise de connexion

Pour distinguer les connexions lancées par l’utilisateur des flux de reprise de connexion, vérifiez la propriété context.protocol :

function (user, context, callback) {
    if (context.protocol === "redirect-callback") {
        // L'utilisateur a été redirigé vers le point de terminaison /continue
    } else {
        // L'utilisateur se connecte directement
    }
}

​

Exemple de changement de mot de passe forcé

Dans certains cas, vous pourriez vouloir forcer les utilisateurs à changer leur mot de passe dans des conditions précises. Vous pouvez écrire une Rule qui se comporte comme suit :

1. L’utilisateur tente de se connecter et doit changer son mot de passe.
2. L’utilisateur est redirigé vers une page propre à l’application avec un JWT dans la chaîne de requête. Ce JWT garantit que seul le mot de passe de cet utilisateur peut être modifié et doit être validé par l’application.
3. L’utilisateur change son mot de passe sur la page propre à l’application, qui appelle la Auth0 Management API
4. Une fois que l’utilisateur a changé son mot de passe avec succès, l’application extrait la revendication authorize_again du JWT vérifié et décodé, puis redirige l’utilisateur vers cette URL pour lui permettre de se connecter avec son nouveau mot de passe.

function(user, context, callback) {
   /*
   * Prérequis :
   * 1. Implémenter une fonction `mustChangePassword`
   * 2. Définir les variables de configuration suivantes :
   *    - CLIENT_ID
   *    - CLIENT_SECRET
   *    - ISSUER
   */

  const url = require('url@0.10.3');
  const req = context.request;

  function mustChangePassword() {
    // TODO : implémenter la fonction
    return true;
  }

  if (mustChangePassword()) {
    // L'utilisateur a initié une connexion et est forcé de changer son mot de passe
    // Envoyer les informations de l'utilisateur et les paramètres de requête dans un JWT pour éviter toute falsification
    function createToken(clientId, clientSecret, issuer, user) {
      const options = {
        expiresInMinutes: 5,
        audience: clientId,
        issuer: issuer
      };
      return jwt.sign(user, clientSecret, options);
    }

    const token = createToken(
      configuration.CLIENT_ID,
      configuration.CLIENT_SECRET,
      configuration.ISSUER,
      {
        sub: user.user_id,
        email: user.email,
        authorize_again: url.format({
          protocol: 'https',
          hostname: auth0.com,
          pathname: '/authorize',
          query: req.query
        })
      }
    );

    context.redirect = {
      url: `https://example.com/change-pw?token=${token}`
    };
  }

  return callback(null, user, context);
}

​

Où stocker les données

Évitez de stocker trop de données dans le profil Auth0. Ces données sont destinées à des fins d’authentification et d’autorisation. Les fonctions de métadonnées et de recherche d’Auth0 ne sont pas conçues pour la recherche marketing ni pour tout autre usage qui exige des recherches intensives ou des mises à jour fréquentes. Votre système risque d’avoir des problèmes d’évolutivité et de performance si vous utilisez Auth0 à cette fin. Il vaut mieux stocker les données dans un système externe et enregistrer un pointeur (l’identifiant de l’utilisateur) dans Auth0 afin que les systèmes backend puissent récupérer les données au besoin. Une règle simple à suivre consiste à stocker uniquement les éléments que vous prévoyez utiliser dans des Rules afin de les ajouter à des jetons ou de prendre des décisions.

​

Considérations de sécurité

Le fait de faire transiter de l’information dans les deux sens par le canal frontal élargit la surface d’attaque exploitable par des acteurs malveillants. Cela ne devrait absolument être fait que lorsque vous devez exécuter une action dans la Rule (par exemple, rejeter la tentative d’autorisation avec UnauthorizedError).

Toutefois, si vous devez communiquer directement avec Auth0 et lui transmettre des instructions pour restreindre l’accès (par exemple, si vous implémentez des vérifications de captcha ou une MFA personnalisée), vous devez disposer d’un moyen sécurisé d’indiquer à Auth0 que les exigences de cette opération ont bien été respectées. De même, si vous devez transmettre de l’information à l’application vers laquelle vous redirigez l’utilisateur, vous devez disposer d’un moyen sécurisé de vous assurer que l’information transférée n’a pas été altérée.

​

Assurez-vous que l’application se connecte avec le même utilisateur

L’application redirigera l’utilisateur vers le locataire Auth0, de sorte que toutes les données liées à l’utilisateur puissent être récupérées au moyen du jeton d’identité renvoyé à l’application. Cependant, vous voudrez peut-être vous assurer que l’application se connecte avec le même utilisateur que celui qui est redirigé, afin de vous assurer qu’il n’y a eu aucune falsification en cours de route. Vous voudrez donc probablement envoyer un jeton avec la requête.

Le jeton envoyé à l’application doit respecter les exigences suivantes :

Élément du jeton	Description
sub	Le user_id Auth0 de l’utilisateur.
iss	Un identifiant qui identifie la Rule elle-même.
aud	L’application ciblée par la redirection.
jti	Une chaîne générée aléatoirement qui est stockée pour confirmation dans l’objet utilisateur (dans le code de la Rule, définissez user.jti = uuid.v4(); puis ajoutez-la comme jti au jeton que vous créez). user.jti sera encore défini lorsque les Rules s’exécuteront de nouveau au moment où /continue sera appelé. Cela est conforme aux spécifications.
exp	Doit être aussi court que possible pour éviter la réutilisation du jeton.
other	Toute autre information de claims personnalisées que vous devez transmettre.
signature	En supposant que l’application dispose d’un emplacement sécurisé pour stocker un secret, vous pouvez utiliser des signatures HS256. Cela réduit grandement la complexité de la solution et, puisque le jeton renvoyé devra lui aussi être signé, c’est une exigence de cette solution. Vous pouvez utiliser RS256, mais cela exige la création d’un certificat et sa mise à jour lorsqu’il expire. Si vous ne renvoyez aucune information directement aux règles, vous pourriez alors utiliser une SPA pour cette application intermédiaire et préférer RS256 afin que l’application n’ait pas à stocker l’information. Vous devrez disposer d’un moyen de valider le jeton, soit au moyen d’un point de terminaison d’introspection, soit au moyen d’un point de terminaison JWKS public.

Ce jeton ne doit pas être traité comme un jeton Bearer ! Il s’agit d’une information signée destinée à être utilisée dans l’application. L’application doit quand même rediriger vers Auth0 pour authentifier l’utilisateur.

​

Transmettre des informations à la Rule

Dans la plupart des cas, même si vous souhaitez transmettre des informations de la Rule à l’application, celle-ci devrait pouvoir les stocker de façon sécuritaire dans l’espace de stockage approprié. Même si l’objectif est de mettre à jour les métadonnées de l’application ou de l’utilisateur dans Auth0, cela peut se faire à l’aide du Management API, et les informations de l’utilisateur seront mises à jour tant que l’opération est terminée avant de rediriger l’utilisateur vers le point de terminaison /continue. Vous ne devriez renvoyer des informations à la Rule que si la Rule elle-même doit recevoir des informations et que celles-ci ne sont pertinentes que pour cette session de connexion précise.

Lors de la transmission d’informations au point de terminaison /continue, le jeton transmis doit respecter les exigences suivantes :

Élément du jeton	Description
sub	Le user_id Auth0 de l’utilisateur.
iss	L’application ciblée par la redirection.
aud	Un identifiant qui désigne la Rule elle-même.
jti	Le même JTI qui a été stocké dans le jeton transmis à l’application (REMARQUE : il doit correspondre à user.jti, sinon l’opération échoue).
exp	Doit être aussi court que possible afin d’éviter la réutilisation du jeton.
other	Toute autre information de claims personnalisés que vous devez transmettre.
signature	En supposant que l’application dispose d’un emplacement sécurisé pour stocker un secret, vous pouvez utiliser des signatures HS256. Cela réduit grandement la complexité de la solution et, puisque le jeton renvoyé devra également être signé, il s’agit d’une exigence de cette solution. Vous pouvez utiliser RS256, mais cela exige la création d’un certificat et sa mise à jour à son expiration.

Il doit être envoyé au moyen de POST, puis récupéré dans context.request.body.token (ou quelque chose de semblable) plutôt que d’être transmis comme paramètre de requête. Cela ressemble à la méthode form-post pour l’authentification.

Si vous ne transmettez pas d’informations au point de terminaison /continue, vous pourriez vouloir ajouter le JTI à une liste d’exclusion, à moins que vos délais d’expiration soient suffisamment courts pour que les attaques par rejeu soient presque impossibles.

​

Restrictions et limites

Les Redirect Rules ne fonctionnent pas avec :

• le point de terminaison Resource Owner
• l’échange par mot de passe
• l’échange de Jeton d’actualisation

Vous pouvez détecter les cas ci-dessus en vérifiant context.protocol :

• Pour l’échange par mot de passe : context.protocol === 'oauth2-password'
• Pour l’échange de Jeton d’actualisation : context.protocol === 'oauth2-refresh-token'
• Pour les connexions Resource Owner : context.protocol === 'oauth2-resource-owner'

​

Délai d’expiration de la session

Les sessions des règles de redirection sont généralement valides pendant 3 jours, à moins que vous n’ayez configuré un délai d’expiration plus court dans vos paramètres de gestion des sessions de connexion. Vous trouverez ces paramètres dans les paramètres avancés de votre locataire.

​

Point de terminaison Resource Owner

Il est impossible d’utiliser des règles de redirection lorsque vous appelez directement /oauth/token pour le Resource Owner Password Grant. Comme l’utilisateur ne se trouve pas dans un flux de redirection au départ, vous ne pouvez pas le rediriger dans une Rule. Si vous tentez de définir context.redirect, la tentative de connexion échouera avec l’erreur interaction_required.

​

Flux où prompt=none

Comme prompt=none vise à éviter toute situation où l’utilisateur devrait saisir une information, toute redirection entraînera un error=interaction_required.

Comme les Rules s’exécutent après la création d’une session d’authentification, vous ne pouvez pas utiliser prompt=none si vous avez une Rule de redirection qui tente de bloquer l’accès aux jetons dans certaines conditions (MFA personnalisée, captcha à la connexion, etc.).

Vous ne pouvez pas créer un flux de redirection qui bloque l’accès aux jetons tout en contournant la Rule de redirection avec prompt=none, car après une tentative échouée, un utilisateur peut simplement relancer l’appel avec prompt=none et obtenir des jetons, puisque sa session d’authentification a été créée même si les Rules ont échoué la première fois.

​

Jetons d’actualisation

Comme l’utilisation d’un jeton d’actualisation nécessite un appel côté serveur à /oauth/token, cela échouera aussi si vous définissez context.redirect.

Il est difficile de vérifier de façon sécuritaire que toutes les restrictions de connexion ont bien été respectées. Il n’existe pas d’identifiant de session stable dans le contexte qui permettrait de recueillir des renseignements associés à la session, par exemple si cet utilisateur a réussi des défis MFA. Par conséquent, vous ne pouvez pas utiliser prompt=none.

Chaque fois que context.redirect est défini dans une Rule, si prompt=none a été transmis, l’autorisation échoue avec error=interaction_required. Cependant, puisque la session de l’utilisateur est créée même si les Rules échouent, nous ne pouvons pas avoir la certitude qu’un utilisateur a réussi tous les défis context.redirect et, par conséquent, nous ne pouvons pas utiliser prompt=none pour obtenir des jetons.

Dans ce cas précis, nous vous recommandons d’utiliser exclusivement des jetons d’actualisation, car vous pouvez vous assurer qu’un utilisateur a réussi les défis si ceux-ci sont requis pour générer un jeton d’actualisation.

​

En savoir plus

• Rediriger les utilisateurs
• Comprendre le fonctionnement du profilage progressif
• Rediriger les utilisateurs avec une méthode de déconnexion différente