Déconnexion (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).

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é.

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.

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.

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.

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.

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.

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.

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.

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.