Fournisseur d’identité unique : Authentication (Authentification)

En savoir plus sur l’authentification des utilisateurs par le biais d’organisations pour les architectures à locataires multiples.

Dans nos scénarios d’architecture, nous fournissons des recommandations générales sur B2B Authentication (authentification C3E), y compris l’utilisation de la Universal Login (Connexion universelle) en tant que meilleure pratique. Nous vous recommandons d’y réfléchir tout en prenant connaissance des conseils donnés ici.

Meilleure pratique

Bien que de nombreux flux d’authentification soient pris en charge dans Auth0, les flux utilisant la connexion universelle Auth0 sont considérés à la fois comme meilleures pratiques de l’industrie et d’Auth0 parce qu’ils fournissent des fonctionnalités d’authentification et de sécurité. En particulier, la connexion universelle dispose de la SSO (Connexion unique) prête à l’emploi et contribue à repousser les cyber-attaques de type hameçonnage et bucket brigade, c’est pourquoi elle devrait être privilégiée lorsque l’utilisateur fournit un mot de passe. Qui plus est, la nouvelle expérience de connexion universelle est le seul mécanisme pris en charge lors de l’utilisation de la fonctionnalité Auth0 Organizations.

L’authentification des utilisateurs nécessite le traitement d’identifiants de premier facteur. Que cette opération soit effectuée par Auth0 ou par un fournisseur d’identité tiers, lorsque vous utilisez la fonction Organizations d’Auth0, vous devez également avoir recours à la Universal Login Experience (Expérience de Connexion Universelle) de la plateforme.

Auth0 ne prend en charge qu’un seul contexte d’utilisateur authentifié par locataire Auth0; les locataires ne peuvent pas passer sélectivement d’un contexte d’utilisateur authentifié à un autre. Le changement de contexte utilisateur a un impact sur toute session SSO active, et cela s’étend à la fonction Organizations d’Auth0. Si les contextes par organisation sont absolument nécessaires, plusieurs locataires Auth0 devront être déployés en production. Étant donné que l’utilisation de plusieurs locataires a des conséquences qui affectent l’authentification unique (SSO), la gestion des profils utilisateurs, etc., vous devriez bien réfléchir avant de suivre cette voie.

​

Connexion à la base de données

Prenons l’exemple de Hoekstra & Associates, et voyons comment cette implémentation d’authentification pourrait se dérouler avec un utilisateur authentifié au moyen d’une connexion de base de données d’Auth0; ici aussi, la plus grande partie du flux de travail décrit sera généralement gérée avec la trousse SDK Auth0 pertinente ou la bibliothèque associée à votre infrastructure technologique :

1. Jennifer de Hoekstra & Associates ouvre un navigateur et se rend sur l’instance Hoekstra & Associates de Travel0 Corporate Booking.

   1. Si elle dispose déjà d’un témoin de session avec l’instance Hoekstra & Associates de Travel0 Corporate Booking, elle sera généralement connectée au système et nous nous arrêterons à cette étape. Pour en savoir plus, consultez Authentification unique.

2. L’instance Hoekstra & Associates de Travel0 Corporate Booking redirige le locataire Travel0 Auth0 à l’aide du Flux de code d’autorisation (avec ou sans PKCE) en appelant le point de terminaison /authorize et en transmettant les paramètres, généralement à l’aide d’une trousse SDK Auth0 ou une bibliothèque tierce :

   1. Redirect_uri : https://hoekstra.corp.travel0.net/login/callback

   2. response_type: code

   3. state : state unique généré dans cette séance

   4. scope : openid profile…

   5. toutes les permissions OIDC supplémentaires nécessaires, en fonction des informations requises sur l’utilisateur.

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

   7. organization : organization Auth0 à utiliser. Lorsque l’organization est connue à l’avance, une requête à /authorize peut inclure ce paramètre, qui est spécifié sous la forme organization=organization_id, où l’ID de l’organization est l’identifiant associé à la définition de l’organization Auth0 correspondante dans votre locataire Auth0. Vous pouvez également omettre le paramètre organization dans l’appel à /authorize et configurer votre locataire Auth0 pour inviter l’utilisateur à sélectionner l’organization appropriée au moment de l’authentification de premier facteur. Pour plus d’informations, consultez Définir le comportement des organizations.

      Si le paramètre organization (organisation) est inclus dans un appel au point de terminaison /authorize, il doit alors être utilisé de manière cohérente pendant toute la durée de la session avec Auth0. La fonctionnalité Organizations (Organisations) n’associe aucune organisation sélectionnée à la session Auth0 SSO, de sorte que l’omission de ce paramètre invitera toujours l’utilisateur à sélectionner l’organisation souhaitée.

3. Le locataire Travel0 Auth0 redirige vers /login pour récupérer les identifiants de l’utilisateur. Si Jennifer dispose déjà d’une session de base de données avec Hoekstra & Associates, les étapes 3 et 4 seront omises. Pour en savoir plus, consultez Authentification unique (SSO).

   1. Une page de connexion universelle s’affiche, que vous pouvez configurer pour inclure des éléments d’image de marque propres à l’organisation, comme décrit dans la section Image de marque.

4. L’utilisateur saisit ses identifiants et clique sur Login (Se connecter).

5. Le locataire Travel0 Auth0 vérifie les identifiants de l’utilisateur; s’ils sont valides, le pipeline Règles s’exécute. Les Règles peuvent être utilisées pour gérer le contrôle d’accès, comme décrit dans la section Autorisation. Si les identifiants de l’utilisateur ne sont pas valides, l’utilisateur sera invité à les saisir à nouveau.

   L’affectation automatique des membres sera effectuée si cette option a été spécifiée. Pour en savoir plus, consultez Octroi d’une adhésion en temps voulu à une connexion d’organisation. Pour manually-assigned Membership (adhésion affectée manuellement) la validation échouera si l’utilisateur n’est pas déjà affecté en tant que membre de l’organisation.

6. Une fois l’authentification de premier facteur et l’exécution des règles réussies, l’utilisateur est redirigé vers le redirect_uri (https://hoekstra.corp.travel0.net/login/callback) avec le state passé à l’étape 2, ainsi qu’un code.

7. L’instance de Travel0 Corporate Booking de Hoekstra & Associates valide le state, puis appelle le locataire Travel0 Auth0 à https://auth.travel0.net/oauth/token, en passant le code et son ID client et son secret client en échange du jeton d’ID. Le jeton d’ID est ensuite utilisé pour générer une session pour https://hoekstra.corp.travel0.net.

8. L’instance de Travel0 Corporate Booking de Hoekstra & Associates affiche la page appropriée à l’utilisateur.

​

Connexion d’entreprise

L’authentification par le biais d’une connexion d’entreprise suit un processus très similaire. Prenons l’exemple de MetaHexa Bank, et voyons comment cette implémentation d’authentification 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 travail décrit sera généralement géré à l’aide de la trousse SDK Auth0 pertinente ou de la bibliothèque associée à votre infrastructure technologique.

1. Marie de MetaHexa Bank ouvre son navigateur et se rend sur l’instance MetaHexa Bank de Travel0 Corporate Booking.

   1. Si elle dispose déjà d’un témoin de session avec l’instance MetaHexa Bank de Travel0 Corporate Booking, elle sera généralement connectée directement au système et nous nous arrêterons à cette étape. Pour en savoir plus, consultez Authentification unique (SSO).

2. L’instance MetaHexa Bank de Travel0 Corporate Booking redirige le locataire Travel0 Auth0 à l’aide du Flux de code d’autorisation (avec ou sans PKCE) en appelant le point de terminaison /authorize et en transmettant les paramètres, généralement à l’aide d’une trousse SDK Auth0 ou d’une bibliothèque tierce :

   1. Redirect_uri : https://metahexa.corp.travel0.net/login/callback

   2. response_type: code

   3. state : state unique généré dans cette séance

   4. scope : openid profile…

   5. toutes les permissions OIDC supplémentaires nécessaires, en fonction des informations requises sur l’utilisateur.

   6. client_id : ID client associé à l’application créée dans le locataire Travel0 Auth0 pour l’instance de MetaHexa Bank de Travel0 Corporate Booking.

   7. organization : organization Auth0 à utiliser. Lorsque l’organization est connue à l’avance, une requête à /authorize peut inclure ce paramètre, qui est spécifié sous la forme organization=organization_id, où l’ID de l’organization est l’identifiant associé à la définition de l’organization Auth0 correspondante dans votre locataire Auth0. Vous pouvez également omettre le paramètre organization dans l’appel à /authorize et configurer votre locataire Auth0 pour inviter l’utilisateur à sélectionner l’organization appropriée au moment de l’authentification de premier facteur. Pour plus d’informations, consultez Définir le comportement des organizations.

      Si le paramètre organization (organisation) est inclus dans un appel au point de terminaison /authorize, il doit alors être utilisé de manière cohérente pendant toute la durée de la session avec Auth0. La fonctionnalité Organizations (Organisations) n’associe aucune organisation sélectionnée à la session Auth0 SSO, de sorte que l’omission de ce paramètre invitera toujours l’utilisateur à sélectionner l’organisation souhaitée.

   8. connection : nom de la connexion d’entreprise Auth0 configurée pour MetaHexa Bank.

      Meilleure pratique

      Fournissez toujours le paramètre connection. S’il n’est pas fourni, l’utilisateur est invité à sélectionner la connexion d’entreprise associée au fournisseur d’identités en amont (IdP), ce qui constitue une étape supplémentaire du point de vue de l’expérience utilisateur.

3. Le locataire Travel Auth0 redirige le fournisseur d’identité de MetaHexa pour authentifier les identifiants de premier facteur.

   1. La page de connexion s’affiche alors, et l’utilisateur saisit ses identifiants. Si Marie dispose déjà d’une session avec le fournisseur d’identité de MetaHexa, les étapes 3 et 4 seront omises. Pour en savoir plus, consultez Authentification unique (SSO).

4. L’utilisateur saisit ses identifiants et clique sur Login (Se connecter).

5. Le pipeline Règles s’exécute dès que l’authentification par le premier facteur est réussie. Les Règles peuvent être utilisées pour gérer le contrôle d’accès, comme décrit dans la section Autorisation. Si les identifiants de l’utilisateur ne sont pas valides, l’utilisateur sera invité à les saisir à nouveau.

L’affectation automatique des membres sera effectuée si cette option a été spécifiée. Pour en savoir plus, consultez Octroi d’une adhésion en temps voulu à une connexion d’organisation. Pour manually-assigned Membership (adhésion affectée manuellement) la validation échouera si l’utilisateur n’est pas déjà affecté en tant que membre de l’organisation.

Les étapes 6 à 8 correspondent à celles décrites dans le scénario Connexion à une base de données, mais où Amintha est l’utilisateur plutôt que Jennifer et où MetaHexa Bank (metahexa.corp.travel0.net) remplacera Hoekstra & Associates.

​

Connexion sociale

L’authentification par le biais d’une connexion de réseau social suit un schéma similaire à celui associé à une connexion d’entreprise, mais le fournisseur d’identité en amont est associé au fournisseur du réseau social plutôt qu’à une organisation particulière.

Les connexions sociales Auth0 sont définies au niveau du locataire. En règle générale, une seule connexion sociale est configurée par fournisseur social et par locataire Auth0, ce qui correspond à une définition de l’ensemble du locataire Auth0. De ce fait, tout consentement fourni par un utilisateur s’appliquera à toutes les organisations Auth0 définies dans un locataire Auth0 et non à une organisation spécifique.

Avec les connexions via les réseaux sociaux, l’isolement des utilisateurs ne peut pas être modélisé de manière cohérente pour chaque organisation. Bien qu’il puisse être tentant de le modéliser en créant plusieurs connexions à un fournisseur de réseau social, par exemple à l’aide de connexions sociales personnalisées, vous devriez vous abstenir de le faire; une telle stratégie peut entraîner la création du même identifiant d’utilisateur dans plusieurs définitions de connexion, ce qui entraînerait forcément des problèmes à terme.