Considérations relatives à la planification de la déconnexion pour votre implémentation IAM B2B.
La déconnexion consiste à mettre fin à une session authentifiée lorsqu’elle n’est plus nécessaire, ce qui réduit le risque que des tiers non autorisés puissent « prendre le contrôle » de la session. En général, cela se fait en offrant une option de déconnexion dans l’interface utilisateur que vous mettez à la disposition de vos utilisateurs. Plusieurs types de sessions peuvent être créés lorsqu’un utilisateur se connecte (p. ex., sessions d’application locales, session Auth0, sessions de tiers), et vous devrez déterminer lesquelles doivent être terminées lorsque l’utilisateur clique sur une option Déconnexion.
Le comportement de déconnexion doit indiquer clairement à l’utilisateur quelle(s) session(s) sont terminées et, idéalement, afficher ensuite une confirmation visuelle de la déconnexion.
Lors de la configuration du comportement de déconnexion, vous devrez tenir compte des éléments suivants :
Quelles sessions doivent être terminées lorsque l’utilisateur lance la déconnexion ?
Quelles informations devez-vous fournir aux utilisateurs pour confirmer quelles sessions ont été terminées ?
Vers où les utilisateurs doivent-ils être redirigés une fois la déconnexion terminée ?
Combien de temps voulez-vous que les sessions durent si les utilisateurs ne lancent pas le processus de déconnexion ?
L’utilisateur final doit-il être déconnecté de toutes ses sessions d’application lorsqu’il se déconnecte d’une seule d’entre elles ?
La session avec l’IdP d’une organisation doit-elle aussi être terminée à la déconnexion ?
Étant donné les différents types de sessions qui peuvent être créés chaque fois qu’un utilisateur se connecte, plusieurs types de déconnexion sont possibles. La déconnexion de l’application locale met fin à la session avec l’application, tandis que la déconnexion Auth0 met fin à la session Auth0. Si vous avez des organisations qui utilisent leur propre IdP, vous pouvez envisager une stratégie de déconnexion fédérée et l’implémenter en conséquence. La déconnexion globale, ou déconnexion unique (SLO), met fin à la session Auth0 et envoie aussi une demande ou un avis de déconnexion aux applications qui s’appuient sur la session Auth0.Les fonctionnalités offertes par votre application, ainsi que votre utilisation de fonctions comme l’authentification unique (SSO), orienteront votre décision quant au type de déconnexion requis et à la confirmation visuelle que vous devrez fournir à vos utilisateurs. Quelle que soit l’option choisie, le processus de déconnexion que vous implémentez doit indiquer clairement à l’utilisateur quelles sessions sont terminées, ainsi que le moment où le processus de déconnexion est terminé.
Si la fonctionnalité de déconnexion d’une application met fin à une session SSO Auth0 utilisée par d’autres applications, l’utilisateur peut perdre du travail s’il a des transactions non validées. Assurez-vous d’ajouter les fonctionnalités nécessaires pour gérer ce type de situation afin de réduire le risque de perte de travail.
Dans certaines situations, on peut s’attendre à ce qu’un utilisateur soit déconnecté de toutes les applications associées lorsqu’il se déconnecte de l’une des applications que vous fournissez. Cela peut toutefois ajouter de la complexité. Cependant, si vous craignez que les utilisateurs ne s’exposent à des risques (en raison de la sensibilité des données ou de facteurs semblables), vous devrez probablement consulter déconnexion unique et l’implémenter en conséquence.
Où rediriger les utilisateurs après la déconnexion
Une fois l’utilisateur déconnecté, il est redirigé vers l’emplacement de votre choix. Cet emplacement correspond à l’URL de redirection de déconnexion, que vous pouvez définir comme paramètre dans le .Les URL utilisées pour rediriger les utilisateurs après la déconnexion doivent être ajoutées à la liste d’autorisation dans le Dashboard afin de réduire les risques de sécurité liés aux redirections ouvertes. Vous pouvez les ajouter à la liste d’autorisation au niveau du locataire ou de l’application.
Si l’utilisateur se déconnecte et que vous le redirigez vers l’application, puis que l’application le redirige vers un fournisseur d’identité qui a toujours une session valide pour cet utilisateur, l’utilisateur sera reconnecté silencieusement à l’application. Il pourrait alors avoir l’impression que le processus de déconnexion n’a pas fonctionné correctement.
Comme tous les utilisateurs ne lancent pas manuellement le processus de déconnexion, Auth0 propose aussi l’expiration de session pour éviter que les sessions restent actives trop longtemps. Ce paramètre est disponible et configurable dans Auth0 Dashboard.
Si vous mettez en œuvre la déconnexion fédérée, vous voudrez probablement aussi mettre en œuvre la déconnexion unique (SLO). Vous pouvez l’aborder de deux façons principales.
La SLO peut complexifier votre système. Assurez-vous donc d’en avoir réellement besoin avant d’y consacrer du temps de développement et de maintenance supplémentaire.
Évitez d’effectuer trop d’appels à votre locataire Auth0 afin de prévenir la limitation de débit et les mauvaises performances. Une bonne pratique consiste à demander de nouveaux jetons uniquement lorsqu’ils ont expiré et qu’un utilisateur effectue une action. Cela évite que des applications simplement ouvertes, mais non utilisées, interrogent continuellement le système pour obtenir de nouveaux jetons.
Il s’agit de loin de l’approche la plus simple pour la déconnexion unique. Chaque application applique une courte période pendant laquelle un utilisateur peut utiliser le système, par exemple de 5 à 10 minutes. À chaque action effectuée par un utilisateur, si cette période a expiré, une redirection vers Auth0 (pour les applications Web classiques) ou l’authentification silencieuse pour les applications monopages côté client sera utilisée pour obtenir de nouveaux jetons. Normalement, de nouveaux jetons seront émis silencieusement grâce à la session (SSO). Toutefois, après la déconnexion, aucune application ne pourra plus obtenir de nouveaux jetons silencieusement, car la session SSO aura été supprimée et l’utilisateur devra saisir de nouveau ses identifiants.
Si vous redirigez automatiquement l’utilisateur directement vers son propre IdP dans le cadre d’une connexion d’entreprise à l’aide du paramètre connection, cette technique peut ne pas fonctionner, sauf si vous effectuez également une déconnexion fédérée
Une autre approche consiste à créer un service de déconnexion capable d’assurer le suivi des sessions d’application et de les supprimer. Chaque application informerait le service de déconnexion lorsqu’elle crée ou supprime une session. Le service de déconnexion aurait soit un accès direct à toutes les sessions côté serveur des applications et les supprimerait directement, soit la possibilité d’effectuer un appel backend vers chaque application pour lui indiquer qu’elle doit supprimer sa session.Cette technique peut être très efficace, car le délai entre le moment où un utilisateur lance la déconnexion et celui où il est déconnecté de toutes les applications est faible. Toutefois, elle peut aussi ajouter de la complexité et prolonger le temps de développement nécessaire à la mise en œuvre. Elle exige également un mécanisme pour s’assurer que les nouvelles applications ajoutées au système sont bien intégrées à ce service.
La déconnexion fédérée de l’utilisateur est un élément que vous devrez peut-être prendre en compte pour votre application. Si vous ou vos clients utilisez un IdP tiers (c.-à-d. autre qu’un fournisseur d’identité de base de données), vous devrez déterminer s’il faut déconnecter l’utilisateur de l’IdP lorsqu’il se déconnecte de votre application. La réponse dépend des attentes de vos utilisateurs. Si l’application ou l’IdP que vous utilisez est étroitement lié à une organisation cliente et fait partie intégrante des activités quotidiennes, il peut être frustrant pour les utilisateurs d’être déconnectés de leur IdP lorsqu’ils se déconnectent de votre application. Sinon, le fait d’être déconnecté de l’IdP peut être normal, voire souhaité dans certains cas. Dans la plupart des scénarios B2B, nos clients estiment qu’il vaut mieux ne pas effectuer de déconnexion fédérée pour un utilisateur.
Nous mettons à votre disposition un guide de planification au format PDF, que vous pouvez télécharger et consulter pour en savoir plus sur les stratégies que nous recommandons.Guide de planification du projet B2B IAM
Authentification
Gérer les utilisateurs
Personnaliser
Auth0 AI
Plateforme