> ## Documentation Index
> Fetch the complete documentation index at: https://translations.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
> 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.
# Rediriger les utilisateurs à partir de Rules
export const AuthCodeBlock = ({filename, icon, language, highlight, children}) => {
const [displayText, setDisplayText] = useState(children);
const [copyText, setCopyText] = useState(children);
const wrapperRef = React.useRef(null);
useEffect(() => {
let unsubscribe = null;
function init() {
if (!window.autorun || !window.rootStore) {
return;
}
unsubscribe = window.autorun(() => {
let processedChildrenForDisplay = children;
let processedChildrenForCopy = children;
for (const [key, value] of window.rootStore.variableStore.values.entries()) {
const escapedKey = key.replaceAll(/[.*+?^${}()|[\]\\]/g, (String.raw)`\$&`);
let displayValue = value;
if (key === "{yourClientSecret}" && value !== "{yourClientSecret}") {
displayValue = value.substring(0, 3) + "*****MASKED*****";
}
processedChildrenForDisplay = processedChildrenForDisplay.replaceAll(new RegExp(escapedKey, "g"), displayValue);
processedChildrenForCopy = processedChildrenForCopy.replaceAll(new RegExp(escapedKey, "g"), value);
}
setDisplayText(processedChildrenForDisplay);
setCopyText(processedChildrenForCopy);
});
}
if (window.rootStore) {
init();
} else {
window.addEventListener("adu:storeReady", init);
}
return () => {
window.removeEventListener("adu:storeReady", init);
unsubscribe?.();
};
}, [children]);
useEffect(() => {
if (!wrapperRef.current) return;
const originalWriteText = navigator.clipboard.writeText.bind(navigator.clipboard);
let isOverriding = false;
const handleClick = e => {
const button = e.target.closest('[data-testid="copy-code-button"]');
if (!button || !wrapperRef.current.contains(button)) return;
isOverriding = true;
navigator.clipboard.writeText = text => {
if (isOverriding) {
isOverriding = false;
navigator.clipboard.writeText = originalWriteText;
return originalWriteText(copyText);
}
return originalWriteText(text);
};
setTimeout(() => {
if (isOverriding) {
isOverriding = false;
navigator.clipboard.writeText = originalWriteText;
}
}, 100);
};
const wrapper = wrapperRef.current;
wrapper.addEventListener('click', handleClick, true);
return () => {
wrapper.removeEventListener('click', handleClick, true);
if (navigator.clipboard.writeText !== originalWriteText) {
navigator.clipboard.writeText = originalWriteText;
}
};
}, [copyText]);
return
{displayText}
;
};
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](/fr-CA/docs/customize/actions/actions-overview).
Pour vous aider dans votre migration, nous proposons des guides pour [migrer de Rules vers Actions](/fr-CA/docs/customize/actions/migrate/migrate-from-rules-to-actions) et [migrer de Hooks vers Actions](/fr-CA/docs/customize/actions/migrate/migrate-from-hooks-to-actions). Nous avons également une page dédiée, [Passer à Actions](https://auth0.com/platform/extensibility/movetoactions), qui présente des comparaisons de fonctionnalités, [une démonstration d’Actions](https://www.youtube.com/watch?v=UesFSY1klrI) 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](https://auth0.com/blog/preparing-for-rules-and-hooks-end-of-life/).
Vous pouvez utiliser les [Auth0 Rules](/fr-CA/docs/customize/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](/fr-CA/docs/secure/multi-factor-authentication).
## Lancer la redirection et reprendre l’authentification
Définissez la propriété `context.redirect` comme suit :
```javascript lines theme={null}
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 :
```http lines theme={null}
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)](/fr-CA/docs/secure/security-guidance/prevent-threats#cross-site-request-forgery).
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 :
export const codeExample1 = `https://{yourDomain}/continue?state={originalState}`;
Si vous utilisez un domaine personnalisé :
```http lines theme={null}
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 :
export const codeExample2 = `https://{yourDomain}/continue?state=abc123`;
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` :
```javascript lines theme={null}
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](https://auth0.com/docs/api/management/v2/users/patch-users-by-id)
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.
```javascript lines expandable theme={null}
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](https://auth0.com/docs/api/authentication/reference#resource-owner)
* [l’échange par mot de passe](/fr-CA/docs/get-started/authentication-and-authorization-flow/resource-owner-password-flow)
* [l’échange de Jeton d’actualisation](/fr-CA/docs/secure/tokens/refresh-tokens)
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](https://manage.auth0.com/#/tenant/advanced).
### 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](/fr-CA/docs/authenticate/login/redirect-users-after-login)
* [Comprendre le fonctionnement du profilage progressif](/fr-CA/docs/manage-users/user-accounts/user-profiles/progressive-profiling)
* [Rediriger les utilisateurs avec une méthode de déconnexion différente](/fr-CA/docs/authenticate/login/logout/redirect-users-after-logout)