Déconnexion (B2B)

Considérations de planification de la déconnexion des utilisateurs pour votre implémentation IAM B2B.

Logout (Déconnexion) La déconnexion est l’action de mettre fin à une session authentifiée lorsqu’elle n’est plus nécessaire, ce qui réduit au minimum la probabilité que des parties non autorisées puissent « prendre le contrôle » de la session. Ceci est généralement réalisé en fournissant une option de déconnexion sur l’interface utilisateur que vous fournissez à vos utilisateurs. Plusieurs types de sessions peuvent être créés lorsqu’un utilisateur ouvre une session (p.ex., sessions d’application locale, session Auth0, sessions de fournisseur d’identité tiers), et vous devrez déterminer lesquelles de ces sessions doivent être terminées lorsque l’utilisateur clique sur une option Logout (Déconnexion).

​

Meilleure pratique

Votre comportement de déconnexion doit indiquer clairement à l’utilisateur quelle(s) session(s) est (sont) interrompue(s) et, idéalement, afficher une confirmation visuelle de la déconnexion par la suite.

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 se déconnecte?
• Quelles informations devez-vous fournir aux utilisateurs pour confirmer la fin des sessions?
• Où les utilisateurs doivent-ils être redirigés après la fin de la déconnexion?
• Combien de temps voulez-vous que les sessions durent 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 d’une seule?
• La session avec le fournisseur d’identité d’une organisation doit-elle aussi être interrompue lors de la déconnexion?

Compte tenu des différents types de sessions qui peuvent être créées chaque fois qu’un utilisateur se connecte, il existe plusieurs types de déconnexion 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 laDéconnexion fédérée et la mettre en œuvre en conséquence. Déconnexion globale ou Déconnexion Unique (SLO), met fin à la session Auth0 et envoie également une demande/avis de déconnexion aux applications qui dépendent de la session Auth0.

Les fonctionnalités offertes par votre application, ainsi que l’utilisation de fonctions comme le Authentification unique (SSO), vous aideront à déterminer le type de déconnexion nécessaire 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 devrait indiquer clairement à l’utilisateur quelles sessions sont terminées et également quand le processus de déconnexion est terminé.

Si la fonction de déconnexion d’une application met fin à une session SSO (authentification unique) d’Auth0 utilisée par d’autres applications, l’utilisateur peut perdre du travail si des transactions n’ont pas été validées. Assurez-vous d’ajouter la fonctionnalité nécessaire pour gérer de telles conditions afin de minimiser la probabilité d’une perte de travail.

Dans certaines situations, un utilisateur peut être amené à se déconnecter de toutes les applications associées quand il se déconnecte de l’une des applications fournies. C’est quelque chose qui peut ajouter de la complexité. Toutefois, si vous craignez que les utilisateurs puissent être vulnérables (peut-être en raison de la sensibilité des données ou autre), vous devrez probablement considérer la Déconnexion unique et la mettre en oeuvre en conséquence.

​

Où envoyer les utilisateurs après la déconnexion

Une fois que votre utilisateur se déconnecte, il sera redirigé vers un emplacement spécifique de votre choix. Cet emplacement est spécifié en tant que URL de redirection de déconnexion, et vous pouvez le définir en tant que paramètre via le Auth0 Dashboard.

Les URL que vous utilisez pour rediriger les utilisateurs après la déconnexion doivent être mises sur la liste blanche dans le Dashboard afin d’atténuer les vulnérabilités de sécurité des redirections ouvertes. Vous pouvez les mettre sur la liste blanche au niveau du locataire ou de l’application.

Si l’utilisateur se déconnecte et que vous le redirigez vers l’application, et que l’application le redirige vers un fournisseur d’identités où il a toujours une session valide, il sera connecté silencieusement à l’application. L’utilisateur peut avoir l’impression que le processus de déconnexion n’a pas fonctionné correctement.

​

Fin automatique des sessions

Il n’est pas courant que tous les utilisateurs enclenchent le processus de déconnexion manuellement, donc Auth0 fournit également un session timeout (délai d’expiration de session) pour éviter des sessions excessivement longues. Ce paramètre est disponible et paramétrable via le Auth0 Dashboard.

​

Déconnexion unique

Si vous utilisez la Déconnexion fédérée vous voudrez surement également faire la Déconnexion unique (SLO), et deux principales approches existent pour y parvenir.

La déconnexion unique (SLO) peut augmenter la complexité de votre système. Assurez-vous donc que cette fonctionnalité est vraiment nécessaire avant de consacrer du temps supplémentaire au développement et à la maintenance de votre système.

​

Jetons de courte durée

​

Meilleures pratiques vous devez éviter de faire trop d’appels à votre locataire Auth0 afin d’éviter des limites anti-attaques et de mauvaises performances. La meilleure pratique consiste à ne demander de nouveaux jetons que si les jetons ont expiré et que l’utilisateur entreprend une action. Cela évitera aux applications qui sont simplement ouvertes, mais pas utilisées, de demander continuellement de nouveaux jetons.

C’est de loin l’approche la plus simple pour une déconnexion unique. Chaque application impose un court délai pendant lequel un utilisateur peut utiliser le système, disons de 5 à 10 minutes. À chaque action effectuée par un utilisateur, si le délai est expiré, une redirection vers Auth0 (pour les applications Web régulières), ou authentification silencieuse pour les applications à page unique côté client, sera utilisée pour obtenir de nouveaux jetons. Habituellement, les nouveaux jetons seront émis silencieusement en raison de la session d’authentification unique (SSO). Cependant, après la déconnexion, toutes les applications ne parviendront pas à obtenir de nouveaux jetons silencieusement, car la session d’authentification unique aura été supprimée et l’utilisateur devra ressaisir ses informations d’identification.

Si vous transférez automatiquement l’utilisateur directement vers son propre IdP dans le cadre d’une connexion d’entreprise à l’aide du paramètre de connexion, vous risquez de ne pas pouvoir utiliser cette technique, à moins que vous ne procédiez également à une Déconnexion fédérée

​

Créer un service de déconnexion

Une autre technique que vous pouvez utiliser consiste à créer un service de déconnexion capable de suivre et de détruire les sessions d’application. Chaque application informerait le service de déconnexion lorsqu’elle crée et supprime une session. Le service (de déconnexion) aurait soit un accès direct à toutes les sessions côté serveur de l’application et les détruirait directement, soit il aurait la possibilité de passer un appel de canal d’appui à chaque application pour indiquer à l’application qu’elle doit supprimer sa session.

Cette technique peut être très efficace parce qu’il y a une faible latence entre le moment où un utilisateur appelle pour se déconnecter et le moment où il est déconnecté de toutes les applications. Cependant, cela peut ajouter de la complexité et aussi du temps de développement supplémentaire pour la mise en oeuvre. Il faudra aussi trouver un moyen de garantir que les nouvelles applications ajoutées au système le soient à ce service.

​

Déconnexion fédérée

La déconnexion utilisateur fédérée est peut-être quelque chose que vous devrez considérer pour votre application. Si vous ou vos clients utiliserez un IdP tiers (c.-à-d., autre chose qu’un fournisseur d’identité de base de données) la question à savoir si vous devez déconnecter l’utilisateur de l’IdP lorsqu’il se déconnecte de votre application, devra être répondue. La réponse dépend de ce à quoi s’attendent vos utilisateurs. Si l’application et/ou l’IdP que vous utilisez sont étroitement liés à une organisation client et constituent un élément central des opérations quotidiennes, il peut alors être frustrant pour les utilisateurs de se déconnecter de leur IdP en se déconnectent de votre application. Dans le cas contraire, une déconnexion de l’IdP peut être attendue, voire même souhaitée dans certains cas. Dans la plupart des scénarios de commerce au détail, nos clients ont trouvé préférable de ne *pas* réaliser une déconnexion fédérée pour un utilisateur.

​

Guide de planification de projet

Nous fournissons un guide de planification en format PDF que vous pouvez télécharger; vous pouvez vous y référer pour de plus amples détails concernant nos stratégies recommandées.

B2B IAM Project Planning Guide