> ## Documentation Index
> Fetch the complete documentation index at: https://docs-dev-docs-event-stream-action-templates.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Rediriger les utilisateurs

> Décrit comment rediriger les utilisateurs vers des URL qui n’ont pas été ajoutées à la liste blanche.

Vous pouvez renvoyer les utilisateurs vers des pages (URL) particulières au sein de votre application après avoir validé leurs jetons d’ID (authentification). Pour voir comment cela fonctionne, consultez [React : guide de démarrage rapide de la connexion](/docs/fr-ca/quickstart/spa/react).

## Rediriger les utilisateurs vers des URL de rappel sur la liste blanche.

Étant donné que les callback URL peuvent être manipulées par des parties non autorisées, Auth0 ne reconnaît que les URL de la liste blanche définies dans le champ **URL de rappel autorisées** des [paramètres de l’application](https://manage.auth0.com/#/applications/\{yourClientId}/settings) comme étant valides. Pour renvoyer les utilisateurs vers les URL de rappel de la liste blanche, il est nécessaire que votre application sache comment poursuivre le parcours de l’utilisateur.

Il existe deux méthodes pour ce faire :

* En utilisant des témoins et de sessions de navigation
* En utilisant des paramètres `state`

Lors de l’authentification d’un utilisateur, le paramètre de requête `redirect_uri` est utilisé comme URL de rappel. C’est ici que votre application reçoit et traite la réponse provenant d’Auth0, et c’est souvent l’URL vers laquelle les utilisateurs sont redirigés une fois l’authentification terminée. Pour en savoir plus sur le fonctionnement de `redirect_uri`, veuillez consulter [Cadre d’applications Authorization OAuth 2.0](/docs/fr-ca/authenticate/protocols/oauth).

<Tabs>
  <Tab title="Témoin ou session du navigateur">
    Vous pouvez utiliser un témoin ou la session du navigateur pour stocker une valeur d’URL de retour. Il s’agit d’une solution simple à mettre en œuvre, mais qui peut poser des problèmes dans les cas où le témoin ne persiste pas. Dans cette situation, deux sessions utilisateur distinctes sont initiées. Chacune d’entre elles a un objectif distinct et doit être prise en compte pour obtenir l’expérience utilisateur souhaitée.

    * **Session SSO fournie par Auth0** : Auth0 fournit une session pour activer  [l’authentification unique (SSO)](/docs/fr-ca/authenticate/single-sign-on) afin de permettre à votre utilisateur de maintenir une session d’authentification sans être invité à fournir ses informations d’identification plus d’une fois. Cette session est maintenue par Auth0 et référencée comme un témoin lié à votre domaine de locataire (ou `CNAME`). Il existe deux [paramètres du locataire](/docs/fr-ca/manage-users/sessions/configure-session-lifetime-settings) qui déterminent la durée de la session Auth0 :

      * La valeur `idle_session_lifetime` correspond au temps pendant lequel la session restera active, même sans interaction.
      * La valeur `session_lifetime` est la durée maximale pendant laquelle la session peut rester active.

      Ces paramètres s’appliquent à toutes les applications au sein de votre locataire et devraient être configurés de manière à correspondre au modèle de sécurité qui correspond à votre cas d’utilisation.
    * **Session d’application** : Votre application doit également conserver le concept de session. Tout au long de la session de l’utilisateur, votre application peut avoir besoin de demander des jetons supplémentaires ou de renouveler ceux qui ont expiré. Vous devez stocker ces jetons dans votre application et les référencer à l’aide d’un identifiant transmis au navigateur au moyen d’un témoin sécurisé.

    Une fois que votre utilisateur s’est authentifié avec Auth0, il incombe à votre application de déterminer la durée de cette session.
  </Tab>

  <Tab title="Paramètres d’état">
    Une autre méthode consiste à créer un lien profond à l’aide du paramètre `state` que votre rappel interprétera pour déterminer un chemin d’acheminement. Cette solution demande un peu plus de travail, mais elle garantit que l’application dispose des informations dont elle a besoin une fois la redirection effectuée. Pour en savoir plus, consultez [Prévenir les attaques et rediriger les utilisateurs avec les paramètres d’état Oauth 2.0](/docs/fr-ca/secure/attack-protection/state-parameters).

    Cette méthode consiste à envoyer une valeur aléatoire lors du lancement d’une demande d’authentification et à la valider lors du traitement de la réponse (cela implique que vous stockez quelque chose du côté de l’application cliente, dans la session ou sur un autre support, qui vous permet d’effectuer la validation). Si vous recevez une réponse dont l’état est incorrect, vous avez probablement fait l’objet d’une attaque, puisqu’il peut s’agir soit d’une réponse à une demande non sollicitée, soit d’une tentative de falsification de la réponse réelle.

    Le type d’application détermine l’emplacement optimal pour stocker les données nécessaires à la validation de la réponse. Par exemple, si une application web progressive utilise un cadre d’applications à page unique, elle peut stocker ces données localement. En revanche, un cadre d’applications Web traditionnel les stockera dans une session côté serveur.
  </Tab>
</Tabs>

## Rediriger les utilisateurs vers d’autres URL

Parfois, l’URL de rappel n’est pas nécessairement l’endroit où vous souhaitez que les utilisateurs soient redirigés après l’authentification. Par exemple, si un utilisateur a l’intention d’accéder à une page protégée dans votre application et que cette action déclenche une demande d’authentification, vous pouvez stocker cette URL pour rediriger l’utilisateur vers la page voulue une fois l’authentification terminée. Stockez l’URL souhaitée en utilisant les méthodes suivantes :

* [Rediriger les utilisateurs avec des paramètres d’état](/docs/fr-ca/secure/attack-protection/state-parameters)
* [Rediriger les utilisateurs à partir des règles](/docs/fr-ca/customize/rules/redirect-users)

Sélectionnez l’option qui convient le mieux à votre type d’application et au type de [flux](/docs/fr-ca/get-started/authentication-and-authorization-flow/which-oauth-2-0-flow-should-i-use) que vous utilisez. Créez la logique nécessaire dans votre application pour récupérer les URL stockées et redirigez vos utilisateurs là où vous souhaitez qu’ils aillent. Les trousses [SDK Auth0](/docs/fr-ca/libraries) incluent également la prise en charge des URL de redirection.

## En savoir plus

* [Rediriger les utilisateurs avec une déconnexion alternative](/docs/fr-ca/authenticate/login/logout/redirect-users-after-logout)
* [Comment fonctionne le profilage progressif](/docs/fr-ca/manage-users/user-accounts/user-profiles/progressive-profiling)
