Passer au contenu principal
Dans nos scénarios d’architecture, nous proposons des conseils généraux sur l’authentification B2B, y compris l’utilisation d’Universal Login comme pratique exemplaire recommandée. Nous vous recommandons de le consulter en parallèle avec les conseils fournis ici.
Pratique exemplaireBien qu’Auth0 prenne en charge de nombreux flux d’authentification, ceux qui utilisent Auth0 Universal Login sont considérés comme une pratique exemplaire, tant dans l’industrie que chez Auth0, puisqu’ils offrent une fonctionnalité et une sécurité optimales. Plus précisément, Universal Login offre l’authentification unique (SSO) prête à l’emploi et aide à atténuer des attaques comme l’hameçonnage et la bucket brigade. Pour cette raison, il devrait être privilégié partout où un utilisateur fournit des identifiants de mot de passe. Il est également important de noter que la nouvelle expérience Universal Login est le seul mécanisme pris en charge lors de l’utilisation de la fonctionnalité Auth0 Organizations.
L’authentification des utilisateurs exige le traitement des identifiants d’authentification du premier facteur. Que ce traitement soit effectué par Auth0 ou par un (IdP) tiers, lorsque vous utilisez la fonctionnalité Auth0 Organizations, vous devez également utiliser l’Universal Login Experience d’Auth0.
Auth0 ne prend en charge qu’un seul contexte d’utilisateur authentifié par Auth0 Tenant ; les tenants ne peuvent pas passer sélectivement d’un contexte d’utilisateur authentifié à un autre. Un changement de contexte utilisateur a une incidence sur toute session SSO active, et cela s’applique aussi à la fonctionnalité Auth0 Organizations. Si des contextes propres à chaque organisation sont absolument nécessaires, plusieurs Auth0 Tenants devront être déployés en production. Comme l’utilisation de plusieurs tenants a des répercussions sur l’authentification unique (SSO), la gestion des profils d’utilisateurs, etc., vous devriez réfléchir attentivement avant d’emprunter cette voie.

​
Connexion à la base de données

Prenons l’exemple de Hoekstra & Associates pour voir comment cette mise en œuvre de l’authentification peut se dérouler pour un utilisateur authentifié au moyen d’une connexion à la base de données Auth0; la majeure partie du flux de travail décrit sera généralement prise en charge à l’aide du SDK Auth0 approprié ou de la bibliothèque associée à votre pile technologique :
Scénarios d’architecture - MOA - Utilisateurs isolés, applications partagées, flux de connexion à la base de données
  1. Jennifer, de Hoekstra & Associates, ouvre son navigateur et accède à l’instance de Travel0 Corporate Booking de Hoekstra & Associates.
    1. Si Jennifer a déjà un témoin de session avec l’instance de Travel0 Corporate Booking de Hoekstra & Associates, elle sera généralement déjà connectée au système, et nous n’irons pas plus loin. Pour en savoir plus, consultez Single Sign-On.
  2. L’instance de Travel0 Corporate Booking de Hoekstra & Associates redirige vers le locataire Auth0 de Travel0 au moyen du flux du code d’autorisation (avec ou sans PKCE), en appelant le point de terminaison /authorize et en transmettant des paramètres, généralement à l’aide d’un SDK Auth0 ou d’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é au cours de cette session
    4. scope : openid profile …
    5. toute portée OIDC supplémentaire nécessaire, selon les renseignements requis sur l’utilisateur.
    6. client_id : identifiant client associé à l’application créée dans le tenant Auth0 Travel0 pour l’instance de Travel0 Corporate Booking de Hoekstra & Associates.
    7. organization : organisation Auth0 à utiliser. Lorsque l’organisation est connue à l’avance, une requête à /authorize peut inclure ce paramètre, indiqué sous la forme organization=organization_id, où organization_id correspond à l’identifiant associé à la définition de l’organisation Auth0 correspondante dans votre tenant Auth0. Vous pouvez également omettre le paramètre organization dans l’appel à /authorize et configurer votre tenant Auth0 pour inviter l’utilisateur à sélectionner l’organisation appropriée dans le cadre de l’authentification du premier facteur. Pour en savoir plus, consultez Define Organization Behavior.
      Si le paramètre organization est inclus dans un appel au point de terminaison /authorize, il doit être utilisé de façon cohérente pendant toute la durée de la session avec Auth0. La fonctionnalité Organizations n’associe aucune organisation sélectionnée à la session SSO Auth0; l’omission de ce paramètre invitera donc toujours l’utilisateur à sélectionner l’organisation souhaitée.
  3. Le tenant Auth0 de Travel0 redirige vers /login pour recueillir les identifiants de l’utilisateur. Si Jennifer a déjà une session de base de données avec Hoekstra & Associates, les étapes 3a et 4 seront sautées. Pour en savoir plus, consultez l’authentification unique.
    1. La page Universal Login, que vous pouvez configurer pour y inclure des éléments de marque propres à l’organisation, comme décrit dans Branding, s’affiche.
  4. L’utilisateur entre ses identifiants et clique sur login.
  5. Le tenant Auth0 Travel0 vérifie les identifiants de l’utilisateur; s’ils sont valides, le pipeline Rules s’exécute. Les règles peuvent servir à gérer le contrôle d’accès, comme décrit dans Authorization. Si les identifiants de l’utilisateur ne sont pas valides, on lui demandera de les saisir à nouveau.
    L’attribution automatique de l’appartenance sera effectuée si cette option a été spécifiée. Pour en savoir plus, consultez Accorder une adhésion juste à temps à une connexion d’organisation. Pour l’adhésion attribuée manuellement, la validation échouera si l’utilisateur n’est pas déjà membre de l’organisation.
  6. Après l’authentification réussie du premier facteur et l’exécution des Rules, l’utilisateur est redirigé vers le redirect_uri (https://hoekstra.corp.travel0.net/login/callback), avec le state transmis à l’étape 2 ainsi qu’un code.
  7. L’instance de Travel0 Corporate Booking de Hoekstra & Associates valide le state, puis appelle le tenant Auth0 de Travel0 à l’adresse https://auth.travel0.net/oauth/token, en transmettant le code ainsi que son client id et son client secret en échange du jeton d’identité. Le jeton d’identité 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 à l’utilisateur la page appropriée.

​
Connexion d’entreprise

L’authentification au moyen d’une connexion d’entreprise suit un processus très semblable. En reprenant notre exemple de MetaHexa Bank, voyons comment cette mise en œuvre de l’authentification peut se dérouler pour un utilisateur authentifié par l’intermédiaire de la connexion d’entreprise de MetaHexa Bank; encore une fois, la majeure partie du flux décrit sera généralement prise en charge à l’aide du SDK Auth0 approprié ou de la bibliothèque associée à votre pile technologique
Scénarios d’architecture - MOA - Utilisateurs isolés, applications partagées, flux de connexion d’entreprise
  1. Amintha de MetaHexa Bank ouvre son navigateur et accède à l’instance de Travel0 Corporate Booking de MetaHexa Bank.
    1. Si Amintha a déjà un témoin de session avec l’instance de Travel0 Corporate Booking de MetaHexa Bank, elle sera généralement déjà connectée au système, et nous nous arrêterons ici. Pour en savoir plus, consultez Authentification unique.
  2. L’instance de Travel0 Corporate Booking de MetaHexa Bank redirige vers le tenant Auth0 de Travel0 en utilisant le flux de code d’autorisation (avec ou sans PKCE) en appelant le point de terminaison /authorize et en transmettant des paramètres, généralement au moyen d’un SDK Auth0 ou d’une bibliothèque tierce :
    1. redirect_uri: https://metahexa.corp.travel0.net/login/callback
    2. response_type: code
    3. state: paramètre d’état unique généré dans cette session
    4. scope: openid profile …
    5. tout scope OIDC supplémentaire nécessaire, selon les renseignements requis sur l’utilisateur.
    6. 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.
    7. organization: organisation Auth0 à utiliser. Lorsque l’organisation est connue d’avance, une requête à /authorize peut inclure ce paramètre, précisé sous la forme organization=organization_id, où organization_id correspond à l’identifiant associé à la définition de l’organisation Auth0 correspondante dans votre tenant Auth0. Sinon, vous pouvez omettre le paramètre organization dans l’appel à /authorize et configurer votre tenant Auth0 pour inviter l’utilisateur à sélectionner l’organisation appropriée dans le cadre de l’authentification du premier facteur. Pour en savoir plus, consultez Définir le comportement de l’organisation.
      Si le paramètre organization est inclus dans un appel au point de terminaison /authorize, il doit être utilisé de façon cohérente pendant toute la durée de la session avec Auth0. La fonctionnalité Organizations n’associe aucune organisation sélectionnée à la session SSO Auth0; l’omission de ce paramètre invitera donc toujours l’utilisateur à sélectionner l’organisation souhaitée.
    8. connection: nom de la connexion d’entreprise Auth0 configurée pour MetaHexa Bank.
      pratique exemplaireFournissez toujours le paramètre connection. Lorsqu’il n’est pas fourni, l’utilisateur est invité à sélectionner la connexion d’entreprise associée au fournisseur d’identité (IdP) en amont, ce qui ajoute une étape du point de vue de l’expérience utilisateur.
  3. Le tenant Auth0 de Travel0 redirige vers l’IdP de MetaHexa afin d’authentifier les identifiants du premier facteur.
    1. La page de connexion s’affiche, et l’utilisateur saisit ses identifiants. Si Amintha a déjà une session avec l’IdP de MetaHexa, les étapes 3a et 4 seront ignorées. Pour en savoir plus, consultez Authentification unique (SSO).
  4. L’utilisateur saisit ses identifiants et clique sur login.
  5. Une fois l’authentification du premier facteur réussie, le pipeline de Rules s’exécute. Les Rules peuvent être utilisées pour gérer le contrôle d’accès, comme décrit dans Autorisation. Si les identifiants de l’utilisateur ne sont pas valides, l’utilisateur sera invité à les saisir de nouveau.
L’attribution automatique de l’adhésion sera effectuée si cette option a été spécifiée. Pour en savoir plus, consultez Accorder une adhésion juste-à-temps à une connexion d’organisation. Pour une adhésion attribuée manuellement, la validation échouera si l’utilisateur n’est pas déjà membre de l’organisation.
Les étapes 6 à 8 correspondront à celles décrites dans le scénario de connexion à la base de données, sauf qu’Amintha sera l’utilisatrice au lieu de Jennifer et que MetaHexa Bank (metahexa.corp.travel0.net) sera utilisée à la place de Hoekstra & Associates.

​
Connexion sociale

L’authentification au moyen d’une connexion sociale suit un modèle semblable à celui d’une connexion d’entreprise, sauf que l’IdP en amont est associé au fournisseur social plutôt qu’à une organisation en particulier.
Les connexions sociales Auth0 sont définies au niveau du tenant. En règle générale, une seule connexion sociale est configurée par fournisseur social pour chaque tenant Auth0, ce qui en fait une définition applicable à l’ensemble du tenant Auth0. Par conséquent, tout consentement accordé par un utilisateur s’appliquera à toutes les organisations Auth0 définies dans un tenant Auth0, et non à une organisation en particulier.
Avec les connexions sociales, l’isolation des utilisateurs ne peut pas être modélisée de façon cohérente pour chaque organisation. Même s’il peut être tentant de modéliser l’isolation des utilisateurs en créant plusieurs connexions vers un fournisseur social, par exemple en utilisant des connexions sociales personnalisées, il faut éviter de le faire; une telle stratégie peut entraîner la création du même ID utilisateur dans plusieurs définitions de connexion, ce qui finira inévitablement par causer des problèmes.