Gérer les sessions sur plusieurs sites avec le SDK Auth0

Décrit le processus avec le SDK auth0-spa-js pour gérer les sessions sur plusieurs sites.

​

Sessions de courte durée

Ce processus montre comment le SDK auth0-spa-js doit être implémenté pour prendre en charge la gestion des sessions sur plusieurs sites. Dans ce scénario, on suppose que le délai d’inactivité du SSO du locataire est réglé à 300 secondes et que l’expiration du ID Token de chaque application SPA est réglée à 150 secondes. Il s’agit d’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 gère toutes les complexités du processus Proof Key for Code Exchange. Aucune intervention ni configuration supplémentaire n’est nécessaire pour que cela fonctionne.

​

Liens profonds

Pour améliorer l’expérience utilisateur, le SDK inclut un paramètre appState pour la méthode loginWithRedirect(). Les détails de l’application en cours sont inclus dans la requête envoyée au serveur Auth, puis renvoyés une fois l’authentification réussie, ce qui permet à l’utilisateur de reprendre son parcours sans interruption.

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

​

Stockage des jetons

Pour conserver les jetons renvoyés de la façon la plus sécuritaire possible, tous les jetons sont placés dans un cache local. Les ID Token et les jetons d’accès sont stockés par paires; les valeurs audience et scope servent à récupérer les jetons au besoin.

De plus, les jetons mis en cache sont supprimés dès qu’un ID Token ou un 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, s’il n’y en a pas, lance un iframe invisible pour récupérer un nouveau jeton. Ainsi, toutes les requêtes vers des API peuvent utiliser cette méthode pour construire l’en-tête Bearer, sans logique supplémentaire pour gérer les jetons expirés.

Dans le guide de démarrage rapide, la vue ExternalService envoie une requête à l’API Express à l’aide de cette fonctionnalité.

​

Avertir les utilisateurs pour qu’ils prolongent leur session

Lorsqu’un utilisateur n’a effectué aucune action entraînant la mise à jour de la session Auth0, Auth0 recommande d’afficher un avertissement lui demandant de choisir explicitement de prolonger 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 prolonger sa session sans avoir à saisir de nouveau ses identifiants.

Pour en savoir plus sur les minuteries d’inactivité et les fenêtres modales d’expiration, consultez URL de déconnexion 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. Une demande de connexion est envoyée
3. L’utilisateur saisit ses identifiants
4. Le cookie SSO (avec date d’expiration) est défini
5. L’échange de jeton est effectué

​

Maintenir la session Auth0

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

2. Appel de getTokenSilently()

3. La ressource est récupérée

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

5. Appel de getTokenSilently()

   1. Ouverture d’une iframe
   2. Échange du jeton

6. La ressource est mise à jour

​

SSO transparent

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

​

Inviter l’utilisateur à prolonger sa session

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

​

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

1. L’utilisateur choisit de se déconnecter

2. logout() est appelé

   1. Le cache des jetons est vidé
   2. Appel à /oidc/logout
   3. Effacement du témoin SSO et suppression des données de session
   4. Redirection de l’utilisateur vers la page de déconnexion

​

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

1. L’utilisateur demande des données d’une ressource protégée
2. Appel de getTokenSilently()
3. Comportement dépendant de l’application

​

Sessions de longue durée

Auth0 prend en charge les sessions de longue durée pour les plans Enterprise. Avec les sessions de longue durée, vous pouvez configurer des limites de session allant 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 vous avez des échéanciers trimestriels, mensuels ou autres, cela vous permet de réduire les obstacles pour les utilisateurs finaux et de donner accès à du contenu et à des fonctionnalités à faible risque. De plus, les entreprises médiatiques peuvent tirer parti des sessions de longue durée pour améliorer l’expérience utilisateur grâce à un accès transparent au contenu. Vous pouvez également 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é.

Le fonctionnement diffère 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 des sessions et Mettre à jour la durée de vie du Jeton d’accès.

​

​

Pour en savoir plus

• Résoudre les erreurs de jeton invalide
• Vérifier les appels d’API