- Délai d’inactivité : Délai après lequel la session d’un utilisateur expirera si le témoin de sa session n’a pas interagi avec le serveur d’autorisation. Il sera remplacé par les limites du système s’il dépasse 3 jours pour les plans en libre-service ou 100 jours pour les plans Enterprise.
- Exiger la connexion après : Délai après lequel un utilisateur devra se reconnecter, peu importe son activité. Il sera remplacé par les limites du système s’il dépasse 30 jours pour les plans en libre-service ou 365 jours pour les plans Enterprise.
- Vous fixez le délai d’inactivité à 3 jours et la limite Exiger la connexion après à 30 jours.
-
Un utilisateur se connecte et les valeurs que vous avez saisies sont définies pour sa session.
- Si l’utilisateur est actif pendant le délai d’inactivité de trois jours, la durée de vie de la session est prolongée de trois jours. Tant que l’utilisateur est actif au cours des trois jours suivants, la durée de vie de sa session est prolongée de trois jours supplémentaires, jusqu’à ce que la limite Exiger la connexion après soit atteinte. À ce moment-là, l’utilisateur devra se connecter à nouveau.
- Si l’utilisateur est inactif pendant trois jours, il sera automatiquement déconnecté.
- Pendant que l’utilisateur est connecté, vous prolongez les limites de durée de vie des sessions existantes. Les nouveaux paramètres ne prendront effet qu’à la fin de la session existante et lorsque l’utilisateur se connectera à nouveau.
- Pendant que l’utilisateur est connecté, vous réduisez les limites de durée de vie existantes. Les nouveaux paramètres prendront effet dès la prochaine activité de l’utilisateur. Cela vous permet de réduire la durée de vie des sessions à des fins de sécurité.
URL de déconnexion propres à l’application
Il y a deux choses importantes à prendre en compte lorsque vous utilisez des URL de déconnexion spécifiques à une application :- Vous devez envoyer le paramètre de requête
client_id
lorsque vous appelez le point de terminaison/oidc/logout
et l’URLid_token_hint
doit figurer dans la liste des URL de déconnexion autorisées de l’application. - Cela mettra fin à la session Auth0 pour l’ensemble du locataire, c’est-à-dire pour toutes les applications définies, et pas seulement celle qui correspond au
client_id
fourni. La transmission declient_id
indique au point de terminaison dedéconnexion
où chercher la liste blanche des URL de déconnexion.
- Minuteur d’inactivité : ajoutez un minuteur au wrapper de la trousse SDK pour React qui s’aligne sur la durée maximale d’inactivité de la session Auth0. Chaque fois qu’un jeton est renvoyé à l’application, réinitialisez le minuteur.
-
Modale de délai d’expiration : lorsque le délai d’expiration atteint 60 secondes, une modale de délai d’expiration doit s’afficher, demandant à l’utilisateur de se déconnecter ou de poursuivre sa session.
- Poursuivre la session : si l’utilisateur choisit de poursuivre sa session, utilisez la méthode
getTokenSilently()
pour demander un nouveau jeton sans rediriger l’utilisateur de la page avec laquelle il est en train d’interagir. - Déconnexion : si l’utilisateur choisit de se déconnecter, la méthode
logout()
doit être appelée pour s’assurer que la session Auth0 est également terminée. - Délai d’inactivité : si le délai d’inactivité est atteint, aucune action immédiate n’est nécessaire. Pour tenir compte du fait que l’utilisateur peut encore être actif dans un autre onglet, le comportement ne doit pas consister à déconnecter l’utilisateur.
- D’autres options consistent à mettre à jour la fenêtre modale avec un bouton de connexion, à utiliser l’événement window.onfocus pour déclencher
getTokenSilently()
, ou à rediriger l’utilisateur vers une page d’accueil.
- Poursuivre la session : si l’utilisateur choisit de poursuivre sa session, utilisez la méthode