Gérer les sessions multisites avec la trousse SDK Auth0

Ce flux de travail montre comment la trousse SDK auth0-spa-js doit être implémenté pour supporter la gestion de sessions multisites. Dans ce scénario, on suppose que le délai d’inactivité de l’authentification unique du locataire est défini sur 300 secondes et que l’expiration du jeton d’ID de chaque application à page unique est définie sur 150 secondes. Ceci est considéré comme une session « de courte durée ».

Pour toutes les méthodes de récupération d’un jeton d’ID ou d’un jeton d’accès, la trousse SDK gère toutes les subtilités de la clé de preuve du flux de production Proof Key for Code Exchange. Aucun effort ou configuration supplémentaire n’est nécessaire pour que cela fonctionne.

Pour améliorer l’expérience utilisateur, la trousse SDK inclut un paramètre appState pour la méthode loginWithRedirect(). Les détails sur l’application actuelle sont regroupés dans le cadre de la requête adressée au serveur d’authentification qui sera renvoyée une fois l’authentification réussie. Permettre une continuation fluide du parcours utilisateur.

Dans le Démarrage rapide, le composant PrivateRoute définit un paramètre d’état de targetUrl et la fonction onRedirectCallback de index.js extrait cette valeur pour rediriger l’utilisateur une fois l’authentification terminée.

Pour conserver les jetons renvoyés stockés de la manière la plus sûre possible, ils sont tous placés dans un cache local. L’identifiant et les jetons d’accès sont stockés sous forme de paires, les valeurs d'audience et de permission étant utilisées pour récupérer les jetons selon les besoins.

De plus, les jetons de cache sont supprimés une fois que le jeton d’ID ou d’accès expire, de sorte que si un jeton se trouve dans le cache, il peut être considéré comme étant toujours valide.

La méthode getTokenSilently() est utilisée pour utiliser le cache de jetons en premier, et s’il n’en existe pas, lancera un iFrame invisible pour en récupérer un nouveau. À cette fin, toutes les requêtes adressées aux API peuvent utiliser cette méthode pour construire l’en-tête de jeton du porteur sans avoir besoin d’une logique supplémentaire pour gérer les jetons expirés.

Dans le Démarrage rapide, l’affichage ExternalService fait une requête à l’API express en utilisant cette caractéristique.

Dans le cas où un utilisateur n’a effectué aucune action susceptible d’entraîner la mise à jour de la session Auth0, Auth0 vous recommande d’envoyer un avertissement à l’utilisateur pour qu’il choisisse de poursuivre explicitement sa session.

L’intention de cette approche permet à la session de devenir inactive si l’utilisateur n’est plus présent, mais fournit par ailleurs un moyen de déclencher l’actualisation silencieuse du jeton afin que l’utilisateur puisse poursuivre sa session sans avoir besoin d’être à nouveau invité à fournir ses informations d’identification.

Pour en savoir plus sur les minuteries d’inactivité et les modalités de délai d’expiration, lisez URL de déconnexion spécifiques à l’application.

1. Authentification initiale

2. Maintien de la session Auth0

3. SSO fluide

4. Invite l’utilisateur à prolonger la session

5. L’utilisateur se déconnecte explicitement de l’application

6. L’utilisateur est renvoyé à l’application initiale après s’être déconnecté

1. Un nouvel onglet est ouvert

2. Demandes de connexion

3. L’utilisateur saisit les informations d’identification

4. Le témoin SSO (avec expiration) est défini

5. Échange de jeton réalisé

1. Demandes de données de l’utilisateur à partir d’une ressource protégée

2. getTokenSilently() appelé

3. Ressource récupérée

4. L’utilisateur met à jour les données de la ressource protégée

5. getTokenSilently() appelé

   1. iFrame ouvert

   2. Échange de jeton réalisé

6. La ressource est mise à jour

1. L’utilisateur accède à une route privée

2. Vérification avec isAuthenticated()

3. Si faux, loginWithRedirect()

1. À 240 secondes, invite l’utilisateur à maintenir la session active avec une fenêtre qui dure 60 secondes

2. Si l’utilisateur choisit de maintenir la session, getTokenSilently()

1. L’utilisateur choisit de se déconnecter

2. logout() appelé

   1. Le cache de jetons est vidé

   2. Appeler /oidc/logout

   3. Supprimer le témoin SSO et les données de session

   4. Rediriger l’utilisateur vers la page de déconnexion

1. Demandes de données de l’utilisateur à partir d’une ressource protégée

2. getTokenSilently() appelé

3. Comportement dépendant de l’application

Auth0 supporte les sessions de longue durée pour les forfaits d’entreprise. Avec les sessions de longue durée, vous pouvez configurer des limites de session avec jusqu’à 100 jours d’inactivité (délai d’inactivité) et jusqu’à un an de durée totale (délai d’expiration absolu). Si vous disposez d’échéanciers trimestriels, mensuels ou autres, cela vous permet de réduire les frictions pour les utilisateurs finaux et de fournir un accès à du contenu et des fonctionnalités à faible risque. De plus, les sociétés de médias peuvent tirer parti de sessions de longue durée pour améliorer l’expérience utilisateur grâce à un accès transparent au contenu. Vous pouvez également faire des choix entre des sessions de longue durée et une validation de mot de passe en fonction de vos exigences en matière d’expérience utilisateur et de sécurité

Les détails du flux de production changeraient dans le cas d’une session de longue durée où la session d’application serait très probablement plus courte que celle d’authentification unique (SSO).

Pour en savoir plus, lisez Limites de durée de vie de la session et Obtenir des jetons d’actualisation.

• Dépannage des erreurs de jeton non valide
• Vérifier les appels d’API