Gérer les sessions multisites avec le SDK Auth0

Décrit le flux de travail à l’aide du SDK auth0-spa-js pour gérer les sessions multisites.

​

Sessions de courte durée

Ce processus montre comment le SDK auth0-spa-js doit être intégré pour prendre en charge la gestion de session multisite. Dans ce scénario, on suppose que le délai d’inactivité du SSO du tenant est réglé à 300 secondes, et que l’expiration du ID Token de chaque application SPA est réglée à 150 secondes. Cela correspond à une session « de courte durée ».

​

Fonctionnalités du SDK

​

Flux PKCE

Pour toutes les méthodes permettant d’obtenir un ID Token ou un jeton d’accès, le SDK prend en charge toute la complexité de la clé de preuve pour l’échange de code. Aucune étape ni configuration supplémentaire n’est nécessaire pour que cela fonctionne.

​

Liens directs

Pour améliorer l’expérience utilisateur, le SDK inclut un paramètre appState pour la méthode loginWithRedirect(). Les renseignements sur l’application en cours sont inclus dans la requête envoyée au serveur Auth et sont renvoyés après une authentification réussie, ce qui assure une continuation fluide du parcours utilisateur.

Dans le Quickstart, le composant PrivateRoute définit le paramètre state targetUrl, et la fonction onRedirectCallback de index.js récupère cette valeur pour rediriger l’utilisateur lorsque l’authentification est terminée.

​

Stockage des jetons

Afin de stocker les jetons renvoyés de la manière la plus sécuritaire possible, tous les jetons sont placés dans un cache local. Les ID Token et jetons d’accès sont stockés par paires, et les valeurs de l’audience et du scope servent à récupérer les jetons au besoin.

De plus, les jetons mis en cache sont supprimés dès que l’ID Token ou le jeton d’accès expire, de sorte que si un jeton se trouve dans le cache, on peut supposer qu’il est encore valide.

​

Appeler des API

La méthode getTokenSilently() utilise d’abord le cache de jetons et, si aucun jeton n’y est stocké, lance un iframe invisible pour en récupérer un nouveau. À cette fin, toutes les requêtes aux API peuvent utiliser cette méthode pour créer l’en-tête du bearer token, sans logique supplémentaire pour gérer les jetons expirés.

Dans le Quickstart, la vue ExternalService effectue une requête vers l’API express à l’aide de cette fonctionnalité.

​

Avertissez les utilisateurs pour qu’ils poursuivent leur session

Lorsqu’un utilisateur n’a effectué aucune action susceptible de mettre à jour la session Auth0, Auth0 recommande d’afficher un avertissement lui demandant de choisir explicitement de poursuivre sa session.

Cette approche permet à la session de devenir inactive si l’utilisateur n’est plus présent, tout en offrant un moyen de déclencher l’actualisation silencieuse du jeton afin qu’il puisse poursuivre sa session sans avoir à saisir de nouveau ses informations d’identification.

Pour en savoir plus sur les délais d’inactivité et les fenêtres modales d’expiration, consultez les URL de logout propres à l’application.

​

Exemple de flux de travail

1. Authentification initiale
2. Maintien de la session Auth0
3. SSO transparent
4. Demander à l’utilisateur de prolonger la session
5. L’utilisateur se déconnecte explicitement de l’application
6. L’utilisateur revient à l’application initiale après s’être déconnecté

​

Authentification initiale

1. Un nouvel onglet s’ouvre
2. Envoi d’une requête de connexion
3. L’utilisateur saisit ses identifiants
4. Le cookie SSO (avec date d’expiration) est défini
5. Échange de jetons effectué

​

Maintenir la session Auth0

1. L’utilisateur demande des données à une ressource protégée

2. getTokenSilently() appelé

3. Ressource récupérée

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

5. getTokenSilently() appelé

   1. Iframe ouverte
   2. Échange de jeton effectué

6. La ressource est mise à jour

​

SSO transparent

1. L’utilisateur accède à une route privée
2. Vérifier avec isAuthenticated()
3. Si faux, loginWithRedirect()

​

Demander à l’utilisateur de prolonger la session

1. Au bout de 240 secondes, demander à l’utilisateur de garder la session active au moyen d’une fenêtre modale affichée pendant 60 secondes
2. S’il choisit de garder la session active, getTokenSilently()

​

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

1. L’utilisateur choisit de se déconnecter

2. logout() est appelé

   1. Vider le cache de jetons
   2. Envoyer une requête à /oidc/logout
   3. Effacer le cookie SSO et supprimer les données de session
   4. Rediriger l’utilisateur vers la page de déconnexion

​

L’utilisateur revient à l’application initiale après s’être déconnecté

1. L’utilisateur demande des données à une ressource protégée
2. getTokenSilently() est appelé
3. Comportement variable selon l’application

​

Sessions de longue durée

Auth0 prend en charge les sessions de longue durée pour les forfaits Enterprise. Avec les sessions de longue durée, vous pouvez configurer des limites de session pouvant aller jusqu’à 100 jours d’inactivité (délai d’expiration d’inactivité) et jusqu’à un an de durée totale (délai d’expiration absolu). Si vos échéances sont trimestrielles, mensuelles ou autres, cela vous permet de réduire les irritants pour les utilisateurs finaux et d’offrir l’accès à du contenu et à des capacités à faible risque. De plus, les entreprises de médias peuvent tirer parti des sessions de longue durée pour améliorer l’expérience utilisateur grâce à un accès fluide au contenu. Vous pouvez aussi choisir entre les sessions de longue durée et la validation du mot de passe selon vos exigences en matière d’expérience utilisateur et de sécurité.

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

Pour en savoir plus, consultez Configurer les limites de durée de vie de la session et Mettre à jour la durée de vie du jeton d’accès.