Concevez la déconnexion pour votre application B2B Auth0 en déterminant quelles sessions locales, Auth0 et d’IdP d’organisation terminer, ainsi que la façon de mettre en œuvre la déconnexion unique, la déconnexion fédérée et les redirections après déconnexion dans plusieurs applications.
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 parties non autorisées puissent « prendre le contrôle » de la session. On y parvient généralement 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., des sessions d’application locales, une session Auth0, des sessions de tiers), et vous devrez déterminer lesquelles de ces sessions doivent être terminées lorsque l’utilisateur clique sur une option de déconnexion.
Le comportement de déconnexion doit permettre à l’utilisateur de comprendre clairement quelle(s) session(s) est/sont terminée(s) 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 points 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 ?
Où les utilisateurs doivent-ils être redirigés une fois la déconnexion terminée ?
Combien de temps souhaitez-vous que les sessions restent actives si les utilisateurs ne déclenchent 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 de l’une d’elles ?
La session avec le fournisseur d’identité d’une organisation doit-elle aussi être terminée lors de 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 locale de l’application 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 fournisseur d’identité, vous pourriez envisager une stratégie de déconnexion fédérée et la mettre en œuvre en conséquence. La déconnexion unique globale, ou (SLO), met fin à la session Auth0 et envoie également une requête 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 mettez en œuvre doit indiquer clairement à l’utilisateur quelles sessions sont terminées et à quel moment 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 pourrait perdre du travail s’il a des transactions non validées. Assurez-vous d’ajouter la fonctionnalité nécessaire pour gérer ce type de situation afin de réduire au minimum 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 se retrouvent en situation de vulnérabilité (en raison de la sensibilité des données, par exemple), vous devrez probablement examiner la déconnexion unique et la mettre en œuvre en conséquence.
Où rediriger les utilisateurs après la déconnexion
Une fois votre utilisateur déconnecté, il sera redirigé vers l’emplacement précis 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 leur déconnexion doivent être ajoutées à la liste d’autorisation dans le Dashboard afin de réduire les risques de vulnérabilités de redirection ouverte. Vous pouvez les ajouter à la liste d’autorisation au niveau du tenant 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é où il a encore une session valide, l’utilisateur sera reconnecté à l’application de façon silencieuse. L’utilisateur peut alors avoir l’impression que le processus de déconnexion n’a pas fonctionné correctement.
Comme tous les utilisateurs ne déclenchent pas manuellement le processus de déconnexion, Auth0 propose aussi un délai d’expiration de session pour éviter que les sessions restent actives trop longtemps. Ce paramètre est disponible et configurable dans l’Auth0 Dashboard.
Si vous mettez en place la Déconnexion fédérée, vous voudrez probablement aussi mettre en place la déconnexion unique (SLO). Il existe deux grandes approches possibles.
Le SLO peut complexifier votre système. Assurez-vous donc d’en avoir réellement besoin avant d’y consacrer du temps supplémentaire en développement et en maintenance.
Vous devez éviter d’effectuer trop de requêtes vers votre tenant Auth0 afin d’éviter la limitation du nombre de requêtes et les mauvaises performances. Une bonne pratique consiste à ne demander de nouveaux jetons que lorsqu’ils ont expiré et qu’un utilisateur effectue une action. Cela évite que des applications simplement ouvertes, mais non utilisées, sondent continuellement le système pour obtenir de nouveaux jetons.
C’est de loin l’approche la plus simple pour la déconnexion unique. Chaque application impose une courte période pendant laquelle un utilisateur peut utiliser le système, par exemple de 5 à 10 minutes. À chaque action effectuée par l’utilisateur, si ce délai est expiré, soit une redirection vers Auth0 (pour les applications Web traditionnelles), soit 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). Cependant, après la déconnexion, aucune application ne pourra plus obtenir de nouveaux jetons silencieusement, puisque 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 au moyen du paramètre connection, cette technique peut ne pas fonctionner, à moins que vous n’effectuiez aussi une déconnexion fédérée
Une autre technique consiste à créer un service de déconnexion capable de suivre et d’invalider les sessions d’application. 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 invaliderait lui-même, soit la capacité d’effectuer un appel back-channel à chaque application pour lui indiquer qu’elle doit supprimer sa session.Cette technique peut être très efficace, puisqu’il y a peu de latence entre le moment où un utilisateur lance la déconnexion et celui où il est déconnecté de toutes les applications. Toutefois, elle peut aussi ajouter de la complexité ainsi que du temps de développement supplémentaire pour la mise en œuvre. Elle exigera également un moyen de s’assurer que les nouvelles applications ajoutées au système sont bien ajoutées à ce service.
La déconnexion des utilisateurs fédérés est peut-être un aspect à prendre en compte pour votre application. Si vous ou vos clients utilisez un IdP tiers (c.-à-d. autre chose qu’un fournisseur d’identité de base de données), vous devrez déterminer s’il faut aussi 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 joue un rôle central dans les 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. Dans le cas contraire, le fait d’être déconnecté de l’IdP peut être normal, voire souhaitable dans certains cas. Dans la plupart des scénarios B2B, nos clients estiment qu’il est préférable de 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 de projet B2B IAM
Assistant
Responses are generated using AI and may contain mistakes.
