Passer au contenu principal
En utilisant la fonctionnalité Organisations d’Auth0, un seul locataire Auth0 peut être provisionné en vue d’un déploiement en production. Sauf dans les scénarios d’architecture les plus complexes, il est recommandé de provisionner un seul locataire Auth0 pour une utilisation en production, car cela facilite l’intégration et l’utilisation de l’authentification unique (SSO), de la gestion des profils des utilisateurs, etc. Selon l’implémentation, vous devrez également tenir compte de certains éléments liés à la configuration de votre locataire Auth0 et de l’intégration correspondante. L’image de marque associée à une organisation est extrêmement précieuse, car l’utilisation d’éléments de marque offre aux utilisateurs un environnement qu’ils connaissent et auquel ils font confiance. L’utilisation d’éléments de marque reconnus renforce également la confiance des utilisateurs envers le traitement sûr et sécuritaire des renseignements qu’ils fournissent (par exemple, leurs justificatifs d’authentification). L’image de marque Auth0 par défaut, prête à l’emploi, devrait donc être remplacée. Pour en savoir plus, consultez Image de marque.

​
Organisations

Vous devriez créer une organisation Auth0 distincte pour chacune des organisations que vous souhaitez prendre en charge. Dans cet exemple, nous créerons l’organisation hoekstra pour représenter Hoekstra & Associates, et l’organisation metahexa pour représenter MetaHexa Bank. Vous pouvez créer des organisations, soit manuellement dans , soit par programmation à l’aide de la .

​
Applications

Selon la manière dont l’implémentation de votre locataire d’organisation est conçue, plusieurs options s’offrent à vous lorsque vous créez des définitions d’application dans votre locataire Auth0. Quelle que soit l’option retenue, le comportement de l’organisation est défini au niveau de l’application. Si vous provisionnez un locataire d’organisation distinct pour chacun de vos clients, vous aurez généralement besoin d’une définition d’application distincte dans Auth0 pour chacun d’eux. Cette configuration implique aussi habituellement l’envoi du paramètre client_id propre à l’application ainsi que du paramètre organization, qui indique l’Organisation Auth0 à utiliser, dans l’appel au point de terminaison /authorize. Pour en savoir plus, consultez Authentification.
Bonne pratiquePour simplifier la configuration et maximiser l’isolation de sécurité, définissez les applications dans Auth0 de façon distincte. Cela permet notamment de configurer séparément des éléments comme les URL de rappel autorisées et, conformément au principe du moindre privilège, de réduire au minimum l’exposition potentielle des informations liées à l’ID client et au Secret client.
Autrement, l’utilisation d’une seule définition d’application dans Auth0 est prise en charge. Dans ce cas, l’utilisateur sera invité à préciser l’organisation requise lors de l’authentification du premier facteur. Cela nécessitera généralement l’utilisation d’un client_id d’application commun, mais le paramètre organization sera omis dans l’appel au point de terminaison /authorize.

​
Connexions

Ensuite, définissez les connexions qui serviront à authentifier les utilisateurs. Dans ce cas-ci, nous définirons une connexion de base de données pour les utilisateurs associés à Hoekstra & Associates et une connexion d’entreprise pour les utilisateurs associés à MetaHexa Bank.
Bonne pratiquePour les organisations avec un seul fournisseur d’identité (IdP), créez une Connexion pour chaque organisation définie afin d’offrir la flexibilité nécessaire à divers scénarios d’utilisation. Par exemple, une seule connexion de base de données ou connexion de base de données personnalisée par organisation vous permet de supprimer facilement les utilisateurs associés à des organisations mises hors service et offre une flexibilité maximale aux organisations ayant des exigences différentes en matière de complexité des mots de passe.
Une fois la Connexion définie, elle peut être associée à l’Organisation Auth0 appropriée au moyen de l’Auth0 Dashboard ou de la Management API. Pour en savoir plus, consultez Activer les connexions d’organisation.

​
Utilisateurs

Pour les utilisateurs authentifiés au moyen de Connexions autres que des connexions de base de données ou des connexions de base de données personnalisées, l’utilisateur est provisionné auprès du (IdP) externe, indépendamment d’Auth0 et selon le processus habituel. En revanche, les utilisateurs authentifiés au moyen de connexions de base de données ou de connexions de base de données personnalisées peuvent être provisionnés de différentes façons. Vous pouvez utiliser Auth0 Dashboard et Management API pour créer directement un utilisateur dans votre locataire Auth0. Nous prenons également en charge la migration automatique et la migration en bloc.
Pour qu’un utilisateur soit provisionné au moyen de Management API ou de Dashboard, vous devez activer directement une connexion de base de données ou une connexion de base de données personnalisée pour au moins une application. Le fait d’activer une connexion de base de données ou une connexion de base de données personnalisée uniquement pour une organisation ne suffit pas.
Les utilisateurs sont ensuite associés à une organisation Auth0 en leur attribuant une adhésion, et une organisation Auth0 peut être configurée pour attribuer automatiquement l’adhésion des utilisateurs ou manuellement.
Pour qu’une adhésion à une organisation puisse être attribuée manuellement à un utilisateur, cet utilisateur doit déjà avoir un profil utilisateur défini dans Auth0. Vous pouvez attribuer manuellement une adhésion au moyen d’Auth0 Dashboard ou de Management API.

​
Invitation

La fonctionnalité Organisation d’Auth0 prend également en charge l’invitation de membres. Dans ce flux de travail, lorsque vous invitez un utilisateur à une application, l’utilisateur est provisionné automatiquement et son adhésion en tant que membre est créée automatiquement.

​
Connexion de base de données

En reprenant l’exemple de Hoekstra & Associates, voyons comment cette implémentation peut se dérouler lorsqu’une connexion de base de données est utilisée dans le cadre de l’invitation d’un utilisateur; la majeure partie du processus décrit est généralement prise en charge au moyen du SDK ou de la bibliothèque Auth0 approprié selon votre pile technologique :
Scénarios d’architecture - MOA - Utilisateurs isolés, applications partagées, flux d’invitation (connexion de base de données)
  1. Jennifer de Hoekstra & Associates reçoit un courriel envoyé par le locataire Auth0 de Travel0 au nom de l’instance Travel0 Corporate Booking de Hoekstra & Associates.
    1. Le courriel a été envoyé comme décrit dans Inviter des membres d’une organisation et peut avoir été déclenché au moyen de l’Auth0 Dashboard ou de la Management API.
  2. Jennifer ouvre le courriel et clique sur le lien qu’il contient. Son navigateur est alors redirigé vers l’instance de Travel0 Corporate Booking de Hoekstra & Associates. L’URL de base utilisée dans le lien est définie comme l’URI de connexion de l’application, qui fait partie de la définition de l’application Travel0 Corporate Booking de Hoekstra & Associates dans le locataire Auth0 de Travel0.
    1. Le lien contient les paramètres organization et organization_name. Le paramètre organization correspond à l’ID de l’Organisation Auth0 correspondante dans votre locataire Auth0. Il sera ensuite transmis au locataire Auth0 à l’étape 3.
    2. Le lien contient également le paramètre invitation, qui sera lui aussi transmis à l’étape 3.
  3. L’instance de Travel0 Corporate Booking de Hoekstra & Associates redirige vers le locataire Auth0 de Travel0 à l’aide du flux de code d’autorisation (avec ou sans PKCE) en appelant le point de terminaison /authorize et en passant des paramètres semblables aux suivants, généralement au moyen 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. 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 locataire Auth0 Travel0 pour l’instance Travel0 Corporate Booking de Hoekstra & Associates.
    7. organization : ID de l’organisation invitante, généralement obtenu à partir du lien figurant dans le courriel décrit à l’étape 2. Il est indiqué sous la forme organization=organization_id, où organization_id correspond à l’identifiant associé à la définition de l’Organisation Auth0 correspondante dans votre locataire Auth0.
    8. invitation : paramètre invitation supplémentaire associé au lien dans le courriel, comme décrit à l’étape 2.
  4. Le locataire Auth0 Travel0 redirige vers /signup/invitation pour recueillir le mot de passe de l’utilisateur.
    1. Une page Universal Login s’affiche; vous pouvez la configurer pour afficher des éléments visuels propres à l’organisation, comme décrit dans Image de marque.
      Le flux d’invitation associé à la fonctionnalité Organisations d’Auth0 ne tient pas compte d’une session SSO active auprès d’Auth0. Si un utilisateur est invité à s’inscrire alors qu’il est déjà connecté, le fait de cliquer sur le lien dans le courriel affichera toujours la page Universal Login associée.
  5. L’utilisateur saisit son mot de passe (ainsi que tout identifiant supplémentaire, comme son nom d’utilisateur) et clique sur Continuer. L’identifiant de l’utilisateur correspond à l’adresse courriel associée à l’utilisateur et ne peut pas être modifié.
  6. Le locataire Travel0 d’Auth0 vérifie les identifiants. S’ils sont valides, l’utilisateur est provisionné et l’appartenance à l’Organisation Auth0 est configurée. L’utilisateur est authentifié implicitement, et le pipeline Rules s’exécute. Les Rules peuvent servir à gérer le contrôle d’accès, comme décrit dans Authorization.
    1. Si les identifiants de l’utilisateur ne sont pas valides, l’utilisateur sera invité à les saisir à nouveau.
  7. Une fois les identifiants vérifiés et les Rules exécutées avec succès, l’utilisateur est redirigé vers le redirect_uri (https://hoekstra.corp.travel0.net/login/callback) avec le state transmis à l’étape 3, ainsi qu’un code.
  8. L’instance de Travel0 Corporate Booking de Hoekstra & Associates valide le state, puis appelle le locataire Auth0 de Travel0 à l’adresse https://auth.travel0.net/oauth/token, en transmettant le code ainsi que son client id et son client secret pour obtenir le ID Token. Le jeton d’identité est ensuite utilisé pour générer une session pour https://hoekstra.corp.travel0.net.
  9. L’instance de Travel0 Corporate Booking de Hoekstra & Associates affiche la page appropriée pour l’utilisateur.

​
Connexion d’entreprise

En reprenant notre exemple de MetaHexa Bank, voyons comment cette implémentation peut se dérouler lorsqu’une connexion d’entreprise est utilisée dans le cadre d’une invitation d’utilisateur; encore une fois, la majeure partie du flux de travail décrit sera généralement gérée au moyen du SDK Auth0 ou de la bibliothèque correspondant à votre pile technologique :
Scénarios d’architecture - MOA - Utilisateurs isolés, applications partagées, flux d’invitation (connexion d’entreprise)
  1. Amintha de MetaHexa Bank reçoit un courriel envoyé par le locataire Auth0 de Travel0 pour le compte de l’instance Travel0 Corporate Booking de MetaHexa Bank.
    1. Le courriel a été envoyé tel que décrit dans Inviter des membres d’une organisation et peut avoir été déclenché au moyen de l’Auth0 Dashboard ou de l’Auth0 Management API.
  2. Amintha ouvre le courriel et clique sur le lien qu’il contient. Cette action redirige son navigateur vers l’instance Travel0 Corporate Booking de MetaHexa Bank. L’URL de base utilisée dans le lien est indiquée comme URI de connexion de l’application et fait partie de la définition de l’application de l’instance Travel0 Corporate Booking de MetaHexa Bank dans le locataire Auth0 de Travel0.
    1. Le lien contient les paramètres organization et organization_name. Le paramètre organization correspond à l’ID de la définition Organisation Auth0 correspondante dans votre locataire Auth0. Il sera transmis au locataire Auth0 dans le cadre de l’étape 3.
    2. Le lien contient également le paramètre invitation, qui sera lui aussi transmis dans le cadre de l’étape 3.
  3. L’instance Travel0 Corporate Booking de MetaHexa Bank redirige vers le locataire Auth0 de Travel0 à l’aide du flux de code d’autorisation (avec ou sans PKCE) en appelant le point de terminaison /authorize et en passant des paramètres semblables aux suivants, 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: state unique généré pour cette session
    4. scope: openid profile …
    5. tout scope OIDC supplémentaire requis, selon les renseignements nécessaires au sujet de l’utilisateur.
    6. client_id: ID client associé à l’application créée dans le locataire Auth0 de Travel0 pour l’instance Travel0 Corporate Booking de MetaHexa Bank.
    7. organization: ID de l’organisation invitante, généralement obtenu au moyen du lien dans le courriel décrit à l’étape 2. Il est indiqué sous la forme organization=organization_id, où organization_id correspond à l’identifiant associé à la définition Organisation Auth0 correspondante dans votre locataire Auth0.
    8. invitation: Paramètre invitation supplémentaire associé au lien dans le courriel, comme décrit à l’étape 2.
  4. Le locataire Auth0 de Travel0 redirige vers /invitation, où Amintha est informée qu’elle sera d’abord redirigée vers l’IdP de MetaHexa pour s’authentifier avec ses identifiants de premier facteur.
    1. L’utilisateur confirme, puis
    2. Auth0 redirige vers l’instance IdP de MetaHexa Bank, où
    3. La page de connexion s’affiche, et l’utilisateur saisit ses identifiants puis clique sur login.
  5. En cas de succès, l’adhésion à l’organisation Auth0 est établie, l’utilisateur est automatiquement authentifié, et le pipeline Rules s’exécute. Les Rules peuvent être utilisées pour gérer le contrôle d’accès comme décrit dans Autorisation.
Les étapes 6 à 8 correspondront à celles décrites dans le scénario Connexion à la base de données, mais Amintha sera l’utilisatrice au lieu de Jennifer, et MetaHexa Bank (metahexa.corp.travel0.net) sera utilisée à la place de Hoekstra & Associates.

​
Connexion sociale

L’invitation au moyen d’une connexion sociale suit un modèle semblable à celui d’une connexion d’entreprise, mais l’IdP en amont est associé au fournisseur d’identité sociale plutôt qu’à une organisation particulière. Pour en savoir plus sur les considérations liées à l’utilisation des connexions sociales, consultez Authentification.