Fournisseur d’identité unique : Déconnexion

Mettre fin à une session authentifiée lorsqu’elle n’est plus nécessaire, autrement dit se déconnecter, est une bonne pratique en matière d’hygiène de sécurité. Fournir une capacité de déconnexion permet d’atténuer un certain nombre de problèmes de sécurité potentiels, y compris la probabilité 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 recommandons d’examiner en même temps que les conseils fournis ici. Pour ce scénario, la déconnexion est presque identique à la déconnexion dans n’importe quel autre système, de sorte qu’elle aura le même niveau de complexité que celui décrit dans notre documentation standard.

En utilisant notre exemple Hoekstra & Associates, le diagramme suivant illustre le flux typiquement rencontré lorsqu’on a affaire à un utilisateur authentifié au moyen d’une connexion Auth0 à la base de données. Nous allons parcourir ce flux pour voir ce qui se passe; notez que la plupart du flux de production décrit sera généralement traité en utilisant la trousse SDK Auth0 pertinente ou 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 locataire Travel0 Auth0 à https://auth.travel0.net avec les paramètres suivants :

   1. returnTo : https://hoekstra.corp.travel0.net/logoutComplete

   2. client_id : L’ID client associé à l’application créée dans le locataire Travel0 Auth0 pour l’instance Hoekstra & Associates de Travel0 Corporate Booking.

      Meilleure pratique

      Définissez les applications indépendamment dans Auth0 pour faciliter la configuration de l’URL returnTo, où le client_id correspondant sert à fournir la validation correcte de l’URL fournie. Pour en savoir plus, consultez Provisionnement.

3. Le locataire Travel0 Auth0 met fin à la session Auth0 établie au nom de l’utilisateur, supprime toute information SSO et redirige le navigateur vers l’URL returnTo indiquée.

4. L’instance Hoekstra & Associates de Travel0 Corporate Booking affiche une page pour informer Jennifer qu’elle s’est déconnectée avec succès, probablement avec un bouton pour se reconnecter si elle le souhaite.

   1. À ce stade, l’instance de Travel0 Corporate Booking voudra également nettoyer la session d’application associée à l’utilisateur.

Pour ce scénario, la mise en œuvre de la déconnexion peut être un peu plus complexe que lors de l’utilisation d’une connexion à une base de données. Vous avez toujours la possibilité de vous déconnecter uniquement de l’application ou de faire en sorte que la déconnexion de l’application entraîne également la déconnexion du locataire Auth0. Cependant, vous pouvez également avoir la possibilité d’autoriser la déconnexion à partir du fournisseur d’identité de l’organisation (IdP), ce que la plupart des applications évitent, en particulier si les utilisateurs ont accès à d’autres applications d’entreprise auxquelles ils peuvent devoir rester connectés. En évitant cette option, les utilisateurs qui cliquent ensuite sur le bouton login sont automatiquement authentifiés sans avoir à fournir de manière interactive des informations d’identification à premier facteur. Une telle fonctionnalité peut donner lieu à une expérience utilisateur inattendue, et vous devez donc envisager de le signaler à l’utilisateur.

En utilisant notre exemple MetaHexa Bank, voyons comment cette implémentation de déconnexion pourrait se dérouler avec un utilisateur authentifié au moyen d’une connexion d’entreprise à MetaHexa Bank; encore une fois, la plupart du flux de production décrit sera généralement traité en utilisant la trousse SDK Auth0 pertinente ou la bibliothèque associée à votre pile technologique :

1. Amintha clique sur logout.

2. L’instance de Travel0 Corporate Booking de MetaHexa Bank redirige le navigateur vers le locataire Travel0 Auth0 à 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 locataire Travel0 Auth0 pour l’instance MetaHexa Bank de Travel0 Corporate Booking.

   3. federated : Paramètre facultatif utilisé pour déconnecter l’utilisateur de l’IdP de MetaHexa Bank. Lorsqu’il est précisé, le navigateur est redirigé vers le point de terminaison /logout associé à l’IdP de MetaHexa Bank, qui met fin à la session de l’utilisateur avant de rediriger le navigateur vers le locataire Travel0 Auth0.

      Meilleure pratique

      Définissez les applications indépendamment dans Auth0 pour faciliter la configuration de l’URL returnTo, où le client_id correspondant sert à fournir la validation correcte de l’URL fournie. Pour en savoir plus, consultez Provisionnement.

Les étapes 3 et 4 correspondent à celles décrites dans le scénario Connexion à une base de données, mais Amintha remplace Jennifer et MetaHexa Bank (metahexa.corp.travel0.net) remplace Hoekstra & Associates.

Dans le contexte des connexions au moyen de réseaux sociaux, la déconnexion suit un schéma similaire à celui associé à une connexion d’entreprise, mais l’IdP en amont est associé au fournisseur social plutôt qu’à une organisation particulière. Il est presque certain que vous ne voudrez jamais exploiter la capacité de déconnexion fédérée avec un fournisseur de connexion par réseau social, car l’expérience utilisateur qui en résulterait serait trop dérangeante.