Passer au contenu principal
Mettre fin à une session authentifiée lorsqu’elle n’est plus nécessaire, autrement dit se déconnecter, constitue une bonne pratique en matière d’hygiène de sécurité. Offrir une fonction de déconnexion aide à atténuer un certain nombre de risques de sécurité potentiels, notamment la possibilité que des personnes non autorisées puissent « prendre le contrôle » d’une session. Dans nos scénarios d’architecture, nous proposons des recommandations d’ordre général sur la déconnexion B2B, que nous vous recommandons de consulter en complément des indications fournies ici. Pour ce scénario, la déconnexion est presque identique à celle de n’importe quel autre système; elle présente donc le même niveau de complexité que celui décrit dans notre documentation standard.

​
Connexion à la base de données

En reprenant l’exemple de Hoekstra & Associates, le schéma suivant illustre le flux généralement observé lorsqu’un utilisateur est authentifié au moyen d’une connexion à la base de données Auth0. Parcourons ce flux pour voir ce qui se passe; notez que la majeure partie du processus décrit est habituellement prise en charge par le SDK Auth0 pertinent ou 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 sert à valider correctement l’URL fournie. Pour en savoir plus, consultez Provisioning.
  3. Le tenant Auth0 de Travel0 met fin à la session Auth0 établie au nom de 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 pour se reconnecter au besoin.
    1. À cette étape, l’instance de Travel0 Corporate Booking voudra habituellement aussi supprimer la session d’application associée à l’utilisateur.
Si vous ne souhaitez pas supprimer la session SSO de l’utilisateur dans Auth0, l’application peut simplement mettre fin à la session d’application sans rediriger vers le point de terminaison /logout du tenant Auth0. Bien que l’utilisateur soit 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 dans le cas d’une connexion à la base de données. Vous pouvez toujours choisir de déconnecter l’utilisateur uniquement de l’application ou faire en sorte que la déconnexion de l’application entraîne aussi sa déconnexion du tenant Auth0. Toutefois, vous pouvez aussi avoir la possibilité de permettre 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 auxquelles ils doivent peut-être rester connectés. Éviter cela peut toutefois faire en sorte que les utilisateurs qui cliquent ensuite sur le bouton login soient authentifiés automatiquement sans devoir fournir de manière interactive leurs identifiants de premier facteur. Cette fonctionnalité peut entraîner 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; encore une fois, la majeure partie du flux décrit sera généralement prise en charge à 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 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: identifiant 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 indépendamment 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 à la base de données, mais avec Amintha à la place de Jennifer et MetaHexa Bank (metahexa.corp.travel0.net) à la place de Hoekstra & Associates.

​
Connexion sociale

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