Rediriger les utilisateurs

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

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.

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.