Skip to main content
Mettre fin à une session authentifiée lorsqu’elle n’est plus nécessaire, autrement dit effectuer une déconnexion, est une bonne pratique sur le plan de l’hygiène de sécurité. Offrir une fonction de déconnexion aide à atténuer plusieurs risques de sécurité potentiels, notamment la possibilité que des parties non autorisées puissent « prendre le contrôle » d’une session. Dans nos scénarios d’architecture, nous fournissons des conseils généraux sur la déconnexion B2B, que nous vous recommandons de consulter en complément des conseils présentés ici. Pour ce scénario, la déconnexion est presque identique à la déconnexion dans n’importe quel autre système; il présente donc le même niveau de complexité que celui décrit dans notre documentation standard.

Connexion de base de données

En reprenant notre exemple de Hoekstra & Associates, le diagramme suivant illustre le flux habituellement observé lorsqu’un utilisateur est authentifié au moyen d’une connexion de base de données Auth0. Parcourons ce flux pour voir ce qui se passe; notez que la plus grande partie du flux de travail décrit sera généralement gérée à l’aide du SDK Auth0 pertinent ou de la bibliothèque associée à votre pile technologique :
Scénarios d’architecture - MOA - Utilisateurs isolés, applications partagées, flux de déconnexion
  1. Jennifer clique sur logout.
  2. L’instance de Travel0 Corporate Booking de Hoekstra & Associates redirige le navigateur vers le tenant Auth0 de Travel0 à l’adresse https://auth.travel0.net avec les paramètres suivants :
    1. returnTo : https://hoekstra.corp.travel0.net/logoutComplete
    2. client_id : ID client associé à l’application créée dans le tenant Auth0 de Travel0 pour l’instance de Travel0 Corporate Booking de Hoekstra & Associates.
      Bonne pratiqueDéfinissez les Applications séparément dans Auth0 afin de faciliter la configuration de l’URL returnTo, où le client_id correspondant est utilisé pour valider correctement l’URL fournie. Pour en savoir plus, consultez Provisioning.
  3. Le tenant Auth0 de Travel0 met fin à la session Auth0 établie pour l’utilisateur, supprime toute information de SSO et redirige le navigateur vers l’URL returnTo indiquée.
  4. L’instance de Travel0 Corporate Booking de Hoekstra & Associates affiche une page pour informer Jennifer qu’elle s’est déconnectée avec succès, probablement avec un bouton lui permettant de se reconnecter au besoin.
    1. À cette étape, l’instance de Travel0 Corporate Booking voudra généralement aussi nettoyer la session d’application associée à l’utilisateur.
Si vous ne souhaitez pas supprimer la session SSO de l’utilisateur avec Auth0, l’application peut simplement mettre fin à la session d’application sans rediriger vers le point de terminaison /logout du tenant Auth0. Même si l’utilisateur sera déconnecté de l’application, il conservera une session SSO avec Auth0. Dans ce cas, vous voudrez probablement l’informer qu’il est toujours connecté au tenant Auth0 et que, s’il clique de nouveau sur login, il se peut qu’on ne lui demande pas d’entrer ses identifiants du premier facteur.

Connexion d’entreprise

Dans ce scénario, la mise en œuvre de la Déconnexion peut être un peu plus complexe que lorsqu’on utilise une connexion de base de données. Vous avez toujours le choix entre fermer la session uniquement dans l’application ou faire en sorte que la déconnexion de l’application entraîne aussi la déconnexion du tenant Auth0. Cependant, vous pourriez aussi avoir la possibilité d’autoriser la déconnexion du (IdP) de l’organisation, ce que la plupart des applications évitent, surtout si les utilisateurs ont accès à d’autres applications d’entreprise dans lesquelles ils doivent peut-être rester connectés. Toutefois, si vous évitez cela, les utilisateurs qui cliquent ensuite sur le bouton login pourraient être authentifiés automatiquement sans devoir fournir de façon interactive leurs identifiants de premier facteur. Cette fonctionnalité peut créer une expérience utilisateur inattendue; vous devriez donc envisager d’en informer l’utilisateur. En reprenant notre exemple de MetaHexa Bank, voyons comment cette mise en œuvre de la Déconnexion pourrait se dérouler pour un utilisateur authentifié au moyen d’une Connexion d’entreprise à MetaHexa Bank; là encore, la majeure partie du flux de travail décrit sera généralement prise en charge à l’aide du SDK Auth0 ou de la bibliothèque appropriée, selon votre pile technologique :
Scénarios d’architecture - MOA - Utilisateurs isolés, applications partagées, flux de déconnexion d’entreprise
  1. Amintha clique sur logout.
  2. L’instance de Travel0 Corporate Booking de MetaHexa Bank redirige le navigateur vers le tenant Auth0 de Travel0 à l’adresse https://auth.travel0.net avec les paramètres suivants :
    1. returnTo: https://metahexa.corp.travel0.net/logoutComplete
    2. client_id: ID client associé à l’Application créée dans le tenant Auth0 de Travel0 pour l’instance de Travel0 Corporate Booking de MetaHexa Bank.
    3. federated:  Paramètre facultatif utilisé pour déconnecter l’utilisateur de l’IdP de MetaHexa Bank. Lorsqu’il est spécifié, le navigateur est redirigé vers le point de terminaison /logout associé à l’IdP de MetaHexa Bank, ce qui met fin à la session de l’utilisateur avant de rediriger le navigateur vers le tenant Auth0 de Travel0.
      Bonne pratiqueDéfinissez les Applications de façon indépendante dans Auth0 afin de faciliter la configuration de l’URL returnTo, où le client_id correspondant est utilisé pour valider correctement l’URL fournie. Pour en savoir plus, consultez Provisioning.
Les étapes 3 et 4 correspondront à celles décrites dans le scénario connexion de base de données, mais avec Amintha au lieu de Jennifer et MetaHexa Bank (metahexa.corp.travel0.net) au lieu de Hoekstra & Associates.

Connexion sociale

Dans le contexte des connexions sociales, la déconnexion suit un modèle semblable à celui associé à une connexion d’entreprise, mais l’IdP en amont est associé au fournisseur social plutôt qu’à une organisation précise. Vous ne voudrez presque certainement jamais recourir à la déconnexion fédérée avec un fournisseur social, car l’expérience utilisateur qui en résulterait serait trop perturbatrice.