> ## 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 à l’AllowList.

# 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: Informations d’identification destinées au client lui-même, plutôt qu’à l’accès à une ressource." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=ID+Tokens">jetons d’identité</Tooltip> (authentification). Pour voir un exemple de fonctionnement, essayez le [React : Quickstart de connexion](/docs/fr-ca/quickstart/spa/react).

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

Comme les URL de rappel peuvent être manipulées par des parties non autorisées, Auth0 ne reconnaît 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 dans l’AllowList, votre application doit savoir comment leur permettre de poursuivre leur parcours.

Il existe deux méthodes pour y parvenir :

* Utiliser des cookies et des sessions de navigateur
* Utiliser des paramètres `state`

Pendant 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 framework d’autorisation OAuth 2.0](/docs/fr-ca/authenticate/protocols/oauth).

<Tabs>
  <Tab title="Cookie ou session du navigateur">
    Vous pouvez utiliser un cookie ou la session du navigateur pour stocker une valeur d’URL de retour. C’est une solution simple à mettre en œuvre, mais elle peut entraîner des problèmes lorsqu’un cookie n’est pas conservé. Dans cette situation, deux sessions utilisateur distinctes sont créées. Chacune a un rôle distinct et demande certaines précautions pour offrir 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 conserver une session d’authentification sans avoir à fournir ses identifiants plus d’une fois. Cette session est maintenue par Auth0 et prend la forme d’un cookie associé au domaine de votre tenant (ou `CNAME`). Deux [paramètres du tenant](/docs/fr-ca/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 tenant et doivent être configurés de façon à correspondre au modèle de sécurité adapté à votre cas d’utilisation.
    * **Session de l’application** : Votre application doit aussi gérer sa propre session. Tout au long de 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 y faire référence à l’aide d’un identifiant renvoyé au navigateur au moyen d’un cookie sécurisé.

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

  <Tab title="Paramètres `state`">
    Comme méthode de rechange, vous pouvez créer un lien direct au moyen du paramètre `state`, que votre URL de rappel interprétera 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 informations dont elle a besoin une fois la redirection terminée. Pour en savoir plus, consultez [Prevent Attacks and Redirect Users with OAuth0 2.0 State Parameters](/docs/fr-ca/secure/attack-protection/state-parameters).

    Avec cette méthode, vous envoyez une valeur aléatoire au moment de lancer une requête d’authentification et vous validez la valeur reçue lors du traitement de la réponse (cela implique que vous stockiez quelque chose du côté de l’application cliente, en session ou dans un autre support, qui vous permet d’effectuer cette validation). Si vous recevez une réponse avec une valeur `state` qui ne correspond pas, vous avez probablement été la cible d’une attaque, car il s’agit soit d’une réponse à une requête non sollicitée, soit d’une tentative de falsification de la réponse légitime.

    Le type de votre application détermine le meilleur endroit où conserver les données qui permettent à votre application de valider la réponse. Par exemple, si une application Web progressive utilise un framework SPA, elle pourrait stocker ces données dans le local storage, tandis qu’un framework 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>

Parfois, l’URL de rappel n’est pas nécessairement celle vers laquelle vous souhaitez 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 rediriger l’utilisateur vers la page souhaitée 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`](/docs/fr-ca/secure/attack-protection/state-parameters)
* [Rediriger les utilisateurs à partir des Rules](/docs/fr-ca/customize/rules/redirect-users)

Choisissez 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 l’URL enregistrée et rediriger vos utilisateurs là où vous souhaitez qu’ils aillent. Les [Auth0 SDKs](/docs/fr-ca/libraries) prennent aussi en charge les URL de redirection.

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

* [Rediriger les utilisateurs avec le logout alternatif](/docs/fr-ca/authenticate/login/logout/redirect-users-after-logout)
* [Comprendre comment fonctionne le profilage progressif](/docs/fr-ca/manage-users/user-accounts/user-profiles/progressive-profiling)