Single Identity Provider: Déconnexion

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 :

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.

​

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 fournisseur d’identité (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 processus 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 :

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.