Fournisseur d’identité unique : Authentication (Authentification)

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.

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.

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 :

Architecture Scenarios - MOA - Isolated Users, Shared Apps, Database Login Flow
  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.

  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.

  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.

Architecture Scenarios - MOA - Isolated Users, Shared Apps, Enterprise Login Flow
  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.

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

  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.

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.

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.