> ## 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. 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.
# Rediriger les utilisateurs depuis les 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) + "*****MASQUÉ*****";
}
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 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](/docs/fr-ca/customize/actions/actions-overview).
Pour vous aider dans votre migration, nous proposons des guides qui vous aideront à [passer de Rules à Actions](/docs/fr-ca/customize/actions/migrate/migrate-from-rules-to-actions) et à [passer de Hooks à Actions](/docs/fr-ca/customize/actions/migrate/migrate-from-hooks-to-actions). Nous avons aussi une page dédiée, [Move to Actions](https://auth0.com/platform/extensibility/movetoactions), qui présente des comparaisons de fonctionnalités, [une démo d’Actions](https://www.youtube.com/watch?v=UesFSY1klrI) 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](https://auth0.com/blog/preparing-for-rules-and-hooks-end-of-life/).
Vous pouvez utiliser les [Auth0 Rules](/docs/fr-ca/customize/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](/docs/fr-ca/secure/multi-factor-authentication).
## Rediriger à partir de Start 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 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 :
```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)](/docs/fr-ca/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` 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 :
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 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 :
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**, 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` :
```javascript lines theme={null}
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](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 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.
```javascript lines expandable theme={null}
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](https://auth0.com/docs/api/authentication/reference#resource-owner)
* [échange de mot de passe](/docs/fr-ca/get-started/authentication-and-authorization-flow/resource-owner-password-flow)
* [échange de Refresh Token](/docs/fr-ca/secure/tokens/refresh-tokens)
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](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 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](/docs/fr-ca/authenticate/login/redirect-users-after-login)
* [Comprendre le fonctionnement du profilage progressif](/docs/fr-ca/manage-users/user-accounts/user-profiles/progressive-profiling)
* [Rediriger les utilisateurs avec le Logout alternatif](/docs/fr-ca/authenticate/login/logout/redirect-users-after-logout)