Rediriger les utilisateurs depuis les Rules

Découvrez comment personnaliser les flux d’authentification en redirigeant les utilisateurs à l’aide de Rules. Parmi les éléments que vous pouvez personnaliser, citons 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 tenants créés à compter du 16 octobre 2023. Les tenants 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 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’offrent les Actions, consultez Comprendre le fonctionnement d’Auth0 Actions.

Pour vous aider dans votre migration, nous proposons des guides qui vous aideront à passer de Rules à Actions et à passer de Hooks à Actions. Nous avons aussi une page dédiée, Move to Actions, qui présente des comparaisons de fonctionnalités, une démo d’Actions et d’autres ressources pour vous accompagner dans cette transition.

Pour en savoir plus sur la dépréciation de Rules et Hooks, consultez notre article 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 place des flux d’authentification personnalisés qui nécessitent une interaction supplémentaire de l’utilisateur au-delà du formulaire de connexion standard. Les règles de redirection sont couramment utilisées pour effectuer une authentification multifacteur (MFA) dans Auth0, mais elles peuvent aussi servir à :

• Des formulaires personnalisés d’acceptation de la politique de confidentialité, des conditions d’utilisation et de divulgation des données.
• Recueillir de manière sécurisée, une seule fois, des données de profil supplémentaires requises.
• Permettre aux utilisateurs d’Active Directory à distance de changer leur mot de passe.
• Exiger des utilisateurs qu’ils fournissent une vérification supplémentaire lorsqu’ils se connectent depuis des lieux inconnus.
• Recueillir plus d’informations sur vos utilisateurs que celles fournies lors de l’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 Authentification multifacteur dans Auth0.

​

Rediriger à partir de Start 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 l’exécution de toutes les Rules terminée, 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 que vous avez 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 envoyée à l’URL de redirection. Par exemple, si votre Rule redirigeait vers https://example.com/foo, Auth0 utiliserait une URL de redirection comme https://example.com/foo?state=abc123. Ainsi, abc123 serait la valeur de 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, mais 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 la requête au point de terminaison /continue. Par exemple, les mises à jour effectuées au moyen de l’Auth0 Management API sont accessibles après la reprise de la transaction.

​

Valider une connexion reprise

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

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

​

Exemple pour forcer un changement de mot de passe

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 changé et doit être validé par l’application.
3. L’utilisateur change son mot de passe sur la page propre à l’application, en demandant à l’application d’envoyer une requête à l’Auth0 Management API
4. Une fois que l’utilisateur a changé son mot de passe avec succès, l’application extrait la claim 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. Implement 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 : implement la fonction
    return true;
  }

  if (mustChangePassword()) {
    // L'utilisateur a amorcé une connexion et doit 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 à l’authentication et à l’autorisation. Les métadonnées et les capacités de recherche d’Auth0 ne sont pas conçues pour les études de marché ni pour tout autre usage exigeant des recherches intensives ou des mises à jour fréquentes. Votre système risque de rencontrer 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 conserver une référence (le user ID) dans Auth0, afin que les systèmes backend puissent récupérer les données au besoin. Une règle simple consiste à ne stocker que les éléments que vous comptez utiliser dans les rules pour les ajouter aux jetons ou prendre des décisions.

​

Considérations de sécurité

Le fait de faire transiter de l’information dans les deux sens par le front channel élargit la surface d’attaque dont peuvent tirer parti des acteurs malveillants. Vous ne devriez le faire que lorsque vous devez absolument 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 mettez en œuvre des vérifications 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é remplies. De même, si vous devez transmettre de l’information à l’application vers laquelle vous redirigez l’utilisateur, vous devez avoir un moyen sécurisé de vous assurer que l’information transférée n’a pas été altérée.

​

S’assurer que l’application ouvre une session pour le même utilisateur

L’application redirigera l’utilisateur vers le tenant Auth0; toutes les données liées à l’utilisateur pourront donc être récupérées au moyen du jeton ID renvoyé à l’application. Cependant, vous voudrez peut-être vous assurer que l’application ouvre bien une session pour le même utilisateur que celui qui est redirigé, afin d’éviter toute altération en cours de route. Il sera donc probablement préférable d’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 identificateur qui identifie la règle elle-même.
aud	L’application ciblée par la redirection.
jti	Une chaîne générée aléatoirement, stockée pour confirmation dans l’objet user (dans le code de la règle, 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 règles s’exécuteront de nouveau au moment de l’appel à /continue. Cela est conforme aux spécifications.
exp	Doit être aussi court que possible pour éviter toute 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 aussi être signé, c’est une exigence de cette solution. Vous pouvez utiliser RS256, mais cela exige la création d’un certificat ainsi que sa mise à jour lorsqu’il expire. Si vous ne transmettez aucune information directement aux règles, vous pourriez utiliser une SPA pour cette application intermédiaire et préférer RS256 afin que l’application n’ait pas à stocker cette information. Cela exigerait que vous disposiez 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.

​

Renvoyer de l’information à la Rule

Dans la plupart des cas, même si vous voulez transmettre de l’information de la Rule à l’application, l’application pourra généralement la stocker de façon sécuritaire à l’endroit 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 de la Management API, et les renseignements sur l’utilisateur seront mis à jour tant que l’opération est terminée avant de rediriger l’utilisateur vers le point de terminaison /continue. Vous ne devriez renvoyer de l’information à la Rule que si la Rule elle-même doit la recevoir et que cette information n’est pertinente que pour cette session de connexion précise.

Lorsque vous renvoyez de l’information 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 identifie 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 la validation échoue).
exp	Il doit être aussi court que possible pour éviter la réutilisation du jeton.
other	Toute autre information de revendications personnalisées que vous devez transmettre.
signature	En supposant que l’application dispose d’un endroit sécuritaire 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 à son expiration.

Il doit être envoyé au moyen de POST, puis récupéré à 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 renvoyez pas d’information au point de terminaison /continue, vous voudrez peut-être ajouter le JTI à la liste de rejet, à moins que vos délais d’expiration soient assez courts pour que les attaques par rejeu soient presque impossibles.

​

Restrictions et limitations

Les Redirect Rules ne fonctionnent pas avec :

• point de terminaison Resource Owner
• échange de mot de passe
• échange de Refresh Token

Vous pouvez repérer les cas ci-dessus en vérifiant context.protocol :

• Pour l’échange de mot de passe : context.protocol === 'oauth2-password'
• Pour l’échange de Refresh Token : context.protocol === 'oauth2-refresh-token'
• Pour les connexions avec Resource Owner : context.protocol === 'oauth2-resource-owner'

​

Délai d’expiration de la session

Les sessions de règle de redirection sont normalement valides pendant 3 jours, sauf si vous avez configuré un délai d’expiration plus court dans vos paramètres de gestion de la session de connexion. Vous trouverez ces paramètres dans les paramètres avancés de votre tenant.

​

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 au départ dans un flux de redirection, vous ne pouvez pas le rediriger dans une Rule. Si vous tentez de définir context.redirect, vous obtiendrez une tentative de connexion échouée avec l’erreur interaction_required.

​

Flux où prompt=none

Puisque l’objectif de prompt=none est d’éviter toute situation où l’utilisateur devrait fournir une entrée, 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 redirect rule 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 et contourne la redirect rule avec prompt=none, car après une tentative échouée, un utilisateur peut simplement envoyer une nouvelle requête avec prompt=none et obtenir des jetons, puisque sa session d’authentification a déjà é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 exige une requête en arrière-plan vers /oauth/token, cela échouera également 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é appliquées. Il n’y a pas d’ID de session cohérent dans le context qui pourrait servir à recueillir de l’information associée à la session, par exemple pour savoir si cet utilisateur a réussi les étapes de vérification MFA. Par conséquent, vous ne pouvez pas utiliser prompt=none du tout.

Chaque fois que context.redirect est défini dans une Rule, si prompt=none a été transmis, l’autorisation échoue avec error=interaction_required. Toutefois, comme la session de l’utilisateur est créée même si les Rules échouent, nous ne pouvons pas tenir pour acquis qu’un utilisateur a franchi toutes les étapes de vérification context.redirect et, par conséquent, nous ne pouvons pas utiliser prompt=none comme moyen d’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 franchi les étapes de vérification si celles-ci sont requises pour générer un jeton d’actualisation.

​

En savoir plus

• Rediriger les utilisateurs
• Comprendre le fonctionnement du profilage progressif
• Rediriger les utilisateurs avec le Logout alternatif