Rediriger les utilisateurs

Décrit comment rediriger les utilisateurs vers des URL qui n’ont pas été ajoutées à l’AllowList.

Vous pouvez rediriger les utilisateurs vers des pages précises (URL) de votre application après avoir validé leurs jetons d’identité (authentification). Pour voir un exemple de fonctionnement, essayez le React : Quickstart de connexion.

​

Rediriger les utilisateurs vers des URL de rappel figurant dans l’AllowList

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. 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.

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) 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 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.

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.

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.

​

Rediriger les utilisateurs vers d’autres URL

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
• Rediriger les utilisateurs à partir des Rules

Choisissez l’option qui convient le mieux à votre type d’application et au type de flux 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 prennent aussi en charge les URL de redirection.

​

En savoir plus

• Rediriger les utilisateurs avec le logout alternatif
• Comprendre comment fonctionne le profilage progressif