> ## 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écrit comment rediriger les utilisateurs vers des URL qui n’ont pas été ajoutées à la liste d’autorisation.

# Rediriger les utilisateurs

Vous pouvez rediriger les utilisateurs vers des pages précises (URL) de votre application après avoir validé leurs <Tooltip tip="ID Token : jeton destiné à l’application cliente elle-même, et non à l’accès à une ressource." cta="Voir le glossaire" href="/fr-CA/docs/glossary?term=ID+Tokens">ID Tokens</Tooltip> (authentification). Pour voir un exemple de ce fonctionnement, essayez le [Démarrage rapide React : connexion](/fr-CA/docs/quickstart/spa/react).

<div id="redirect-users-to-callback-urls-on-the-allowlist">
  ## Rediriger les utilisateurs vers des URL de rappel figurant sur l’AllowList
</div>

Comme les URL de rappel peuvent être manipulées par des parties non autorisées, Auth0 ne considère comme valides que les URL figurant dans l’AllowList définie dans le champ **Allowed Callback URLs** des [paramètres d’une application](https://manage.auth0.com/#/applications/\{yourClientId}/settings). Pour renvoyer les utilisateurs vers des URL de rappel figurant sur l’AllowList, votre application doit savoir comment poursuivre leur parcours.

Il existe deux façons de procéder :

* Utiliser des cookies et des sessions de navigateur
* Utiliser 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 là que votre application reçoit et traite la réponse d’Auth0, et c’est souvent vers cette URL que les utilisateurs sont redirigés une fois l’authentification terminée. Pour en savoir plus sur le fonctionnement de `redirect_uri`, consultez [le cadre d’autorisation OAuth 2.0](/fr-CA/docs/authenticate/protocols/oauth).

<Tabs>
  <Tab title="Cookie ou session de navigateur">
    Vous pouvez utiliser un cookie ou la session du navigateur pour stocker une valeur d’URL de retour. Il s’agit d’une solution simple à mettre en œuvre, mais elle peut poser problème si un cookie n’est pas conservé. Dans ce cas, deux sessions utilisateur distinctes sont lancées. Chacune a un objectif distinct et nécessite certaines considérations pour offrir l’expérience utilisateur souhaitée.

    * **Session SSO fournie par Auth0** : Auth0 fournit une session pour activer l’[authentification unique (SSO)](/fr-CA/docs/authenticate/single-sign-on), ce qui permet à l’utilisateur de conserver une session d’authentification sans avoir à saisir ses identifiants plus d’une fois. Cette session est maintenue par Auth0 et stockée sous forme de cookie associé au domaine de votre locataire (ou `CNAME`). Deux [paramètres du locataire](/fr-CA/docs/manage-users/sessions/configure-session-lifetime-settings) déterminent la durée de la session Auth0 :

      * `idle_session_lifetime` correspond à la durée pendant laquelle la session reste active sans interaction.
      * `session_lifetime` correspond à la durée maximale pendant laquelle la session peut rester active.

      Ces paramètres s’appliquent à toutes les applications de votre locataire et doivent être configurés en fonction du modèle de sécurité correspondant à votre cas d’utilisation.
    * **Session de l’application** : Votre application doit également maintenir une notion de session. Pendant la session utilisateur, votre application peut devoir demander des jetons supplémentaires ou renouveler ceux qui ont expiré. Vous devriez stocker ces jetons dans votre application et les référencer au moyen d’un identifiant renvoyé au navigateur à l’aide d’un cookie sécurisé.

    Une fois que l’utilisateur s’est authentifié auprès d’Auth0, c’est à votre application de déterminer combien de temps cette session est conservée.
  </Tab>

  <Tab title="Paramètres state">
    Comme solution de rechange, vous pouvez créer un lien profond à l’aide du paramètre `state`, que votre URL de rappel interpréterait pour déterminer le chemin de redirection. Cette solution demande un peu plus de travail à mettre en œuvre, mais elle garantit que l’application dispose des renseignements dont elle a besoin une fois la redirection terminée. Pour en savoir plus, consultez [Prévenir les attaques et rediriger les utilisateurs avec les paramètres state d’OAuth 2.0](/fr-CA/docs/secure/attack-protection/state-parameters).

    Avec cette méthode, vous envoyez une valeur aléatoire au moment de lancer une demande d’authentification, puis vous validez la valeur reçue lors du traitement de la réponse (cela suppose que vous stockiez quelque chose du côté de l’application cliente, dans la session ou dans un autre support, pour effectuer cette validation). Si vous recevez une réponse dont la valeur state ne correspond pas, vous avez probablement été la cible d’une attaque, car 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 de votre application détermine le meilleur endroit où conserver les données permettant à votre application de valider la réponse. Par exemple, si une application Web progressive s’appuie sur un cadre SPA, elle pourrait stocker ces données dans le stockage local, tandis qu’un cadre d’application Web traditionnel les stockerait dans une session côté serveur.
  </Tab>
</Tabs>

<div id="redirect-users-to-other-urls">
  ## Rediriger les utilisateurs vers d’autres URL
</div>

Il arrive que l’URL de rappel ne soit pas forcément celle vers laquelle vous voulez rediriger les utilisateurs après l’authentification. Par exemple, si un utilisateur tente d’accéder à une page protégée de votre application et que cette action déclenche une demande d’authentification, vous pouvez enregistrer cette URL afin de le rediriger vers la page voulue une fois l’authentification terminée. Enregistrez l’URL souhaitée à l’aide des méthodes suivantes :

* [Rediriger les utilisateurs avec des paramètres state](/fr-CA/docs/secure/attack-protection/state-parameters)
* [Rediriger les utilisateurs à partir de Rules](/fr-CA/docs/customize/rules/redirect-users)

Choisissez l’option qui convient le mieux à votre type d’application et au type de [flux](/fr-CA/docs/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 l’URL enregistrée et rediriger vos utilisateurs vers la destination voulue. Les [SDK Auth0](/fr-CA/docs/libraries) prennent également en charge les URL de redirection.

<div id="learn-more">
  ## En savoir plus
</div>

* [Rediriger les utilisateurs au moyen d’une déconnexion alternative](/fr-CA/docs/authenticate/login/logout/redirect-users-after-logout)
* [Comprendre le fonctionnement du profilage progressif](/fr-CA/docs/manage-users/user-accounts/user-profiles/progressive-profiling)