La façon dont vous configurez l’architecture de votre locataire Auth0 a une incidence sur votre implémentation B2B IAM.
Comprendre votre application est essentiel pour voir comment Auth0 peut être utilisé afin de répondre à vos besoins. D’après notre expérience, nos clients les plus performants commencent par visualiser leur architecture cible — ou, dans bien des cas, leur architecture existante — et s’y réfèrent tout au long de leur progression. Il est également important de comprendre où s’inscrit votre application dans votre organisation; les comptes et locataires Auth0 constituent la base du regroupement et de la structuration des ressources Auth0, et il se peut que vous deviez tirer parti d’un déploiement Auth0 existant pour intégrer le Single Sign-on (SSO), la gestion centralisée des profils, la facturation consolidée ou d’autres fonctionnalités du même type.
Si vous avez plusieurs applications et que vous devez tirer parti du SSO, nous vous recommandons de consulter notre guide de formation How to Implement Single Sign-On avant de poursuivre.
Investir du temps dès le départ pour définir le paysage architectural est, selon notre expérience, un effort rentable à long terme. Voici plusieurs éléments à prendre en compte lorsque vous évaluez les fonctionnalités et les flux de travail :
À quoi l’URL devrait-elle ressembler lorsque Auth0 doit présenter une page web à un utilisateur ?
Comment Auth0 peut-il être structuré pour prendre en charge votre SDLC (cycle de vie du développement logiciel) ?
Comment vous assurer que vos locataires Auth0 sont correctement associés à votre contrat ?
Que devez-vous prendre en compte si d’autres projets de votre organisation s’intègrent à Auth0 ? Plus particulièrement, des projets qui ciblent leur propre domaine d’utilisateurs, ou un domaine différent (par exemple, des applications utilisées uniquement par des employés) ?
Comment harmoniser la structure et le domaine de l’organisation de vos clients avec votre déploiement Auth0 ?
Les organisations desservent souvent plus d’un domaine d’utilisateurs — les clients, les employés et les affiliés étant les plus courants — avec généralement peu ou pas de chevauchement : les employés, par exemple, n’utilisent pas les mêmes applications que les clients, et vice-versa. Dans certains cas, il peut aussi être nécessaire de subdiviser davantage un domaine — par exemple, en groupes distincts de clients qui utilisent des produits différents et non connectés. Auth0 offre un moyen de séparer vos utilisateurs et les ressources associées, et le provisionnement du locataire traite ce sujet plus en détail. Si vous devez mettre en service un locataire indépendant, vous voudrez aussi l’associer à votre compte Auth0 existant, afin de tirer pleinement parti des avantages offerts par le niveau d’abonnement contracté par votre organisation.
Il n’est pas rare que des entreprises aient des exigences en matière d’identité visant plusieurs communautés d’utilisateurs : clients, partenaires, employés, etc. Assurez-vous donc de tenir compte d’autres projets ou de besoins futurs lorsque vous concevez votre architecture.
De plus, vous aurez sans doute déjà mis en place un ensemble de processus et de procédures dans le cadre de votre cycle de vie du développement logiciel (SDLC). Vous voudrez donc aussi consulter nos conseils sur la prise en charge du SDLC en ce qui concerne le provisionnement du locataire Auth0.Pour les applications destinées aux clients, nous constatons généralement que OpenID Connect (OIDC) est le protocole le plus couramment utilisé. OIDC repose sur des flux web avec des URL de navigateur présentées à l’utilisateur. Par défaut, les URL destinées aux clients dans le cadre de la prise en charge d’OIDC par Auth0 portent la marque Auth0; toutefois, nous recommandons d’utiliser la fonctionnalité de domaine personnalisé d’Auth0 afin d’assurer une image de marque cohérente et de répondre aux préoccupations potentielles des utilisateurs en matière de confiance avant qu’elles ne surviennent.
D’autres groupes au sein de votre organisation travaillent peut-être aussi avec Auth0; il n’est pas rare que nos clients aient des services distincts qui desservent différentes communautés d’utilisateurs. Le fait de les cerner peut influencer vos choix de conception, et le faire tôt peut vous éviter des décisions qui pourraient s’avérer coûteuses par la suite.
Si certaines ou toutes les organisations de vos clients ont chacune besoin de leur propre URL personnalisée, ou si elles utilisent des fournisseurs sociaux qui nécessitent une page de consentement personnalisée aux couleurs de l’organisation, nous vous recommandons de créer des locataires Auth0 distincts pour ces organisations; consultez Provisionnement du locataire pour les organisations complexes pour plus de détails.
Tout commence par un locataire Auth0. C’est là que vous configurerez votre utilisation d’Auth0 et que les ressources Auth0, comme les Applications, les Connexions et les profils d’utilisateur, sont définies, gérées et stockées. L’accès à un locataire Auth0 se fait au moyen du Dashboard d’Auth0. À partir du Dashboard, vous pouvez aussi créer des locataires supplémentaires associés. Vous pouvez créer plus d’un locataire Auth0 afin de structurer vos locataires de façon à isoler différents domaines d’utilisateurs et à prendre en charge votre cycle de vie du développement logiciel (SDLC).
Les noms de locataire ne peuvent pas être modifiés ni réutilisés après leur suppression. Assurez-vous donc que ces noms vous conviennent avant de créer vos locataires Auth0.
Déterminer le niveau d’isolation requis pour vos domaines d’utilisateurs est une étape importante et, avec vos exigences en matière d’image de marque, vous aidera ensuite à déterminer le nombre de locataires Auth0 nécessaires dans votre environnement de production. Comme nous recommandons de créer un ensemble complet de locataires prenant en charge le SDLC pour chaque locataire Auth0 exploité dans un environnement de production, le nombre de locataires Auth0 à gérer peut rapidement augmenter. Vous devriez donc bien réfléchir avant de créer plusieurs locataires Auth0 pour la production et consulter nos directives sur l’Image de marque avant de prendre votre décision finale.
Provisionnement du locataire pour des organisations complexes
Dans la plupart des cas, il n’est pas nécessaire de provisionner des locataires Auth0 distincts pour les organisations de vos clients. Cela est devenu encore plus simple avec le lancement de notre nouvelle fonctionnalité Organisations. Toutefois, dans certaines circonstances, cela peut s’avérer utile pour réduire la complexité de votre configuration. Par exemple, comme bonne pratique, nous recommandons de provisionner un locataire Auth0 distinct pour l’organisation de vos clients si :
Les organisations de vos clients ont besoin d’une URL de connexion personnalisée qui leur est propre. C’est généralement le cas seulement si vous leur permettez d’avoir leur propre URL personnalisée plutôt que d’utiliser une URL de connexion commune. Auth0 prend en charge un par locataire.
Les organisations de vos clients utilisent des fournisseurs sociaux pour la connexion. Dans ce cas, il est souvent souhaitable que l’organisation dispose d’une page de consentement personnalisée du fournisseur social, à son image.
Si l’une ou l’autre de ces situations s’applique, nous recommandons de créer un locataire Auth0 distinct pour chaque organisation qui répond à l’un des critères ci-dessus.
La gestion de plusieurs locataires Auth0 peut ajouter de la complexité à votre système et ne devrait être envisagée qu’en cas de nécessité absolue.
Pour vous assurer que vos locataires sont tous associés à votre contrat Auth0 et qu’ils disposent des mêmes fonctionnalités, assurez-vous que tous vos locataires sont associés au compte de votre entreprise. Si certains développeurs veulent créer leurs propres environnements bac à sable pour effectuer des tests, veillez à ce qu’ils soient également associés à votre compte afin qu’ils aient les mêmes autorisations. Pour ce faire, communiquez avec votre représentant Auth0 ou le Centre de soutien Auth0.
Lorsque vous configurez votre locataire Auth0, l’URL permettant d’y accéder est de la forme https://{yourTenant}.auth0.com. Fournir un Domaine personnalisé (également appelé URL vanity) pour votre locataire Auth0 est non seulement un élément important pour répondre à vos besoins en matière d’image de marque, mais offre aussi, et surtout, des avantages sur le plan de la sécurité :
Il est plus difficile d’hameçonner votre domaine si vous avez une URL vanity, puisque l’hameçonneur doit lui aussi créer une URL vanity pour imiter la vôtre. Par exemple, avec un domaine personnalisé, vous pouvez utiliser votre propre certificat pour obtenir une « validation étendue », ce qui complique encore davantage l’hameçonnage.
Un seul domaine personnalisé est autorisé par locataire Auth0. Cela s’explique par le fait qu’un locataire Auth0 est censé représenter un « domaine » d’utilisateurs. Si vous avez besoin de plus d’une URL vanity, il est probable que vous ayez plus d’un domaine d’utilisateurs et que vous deviez utiliser plusieurs locataires.
Le nom de votre domaine personnalisé doit aussi inspirer confiance à l’utilisateur et lui indiquer qu’il s’agit du bon endroit où saisir ses identifiants. Nous vous recommandons également de créer votre domaine personnalisé dans tous les environnements dès le début afin d’assurer des tests cohérents d’un environnement à l’autre. Il est extrêmement important d’apprendre à vos utilisateurs à repérer les URL suspectes lorsqu’ils saisissent leurs identifiants !
Créez un domaine personnalisé (c.-à-d. CNAME) pour votre locataire Auth0, et créez-en aussi un en développement afin de vous assurer que vous avez correctement configuré le CNAME. Par exemple, vous pourriez créer un CNAME qui fait correspondre login.mycompany.com à mycompany-prod.auth0.com.
Dans presque tous les cas, les clients obtiennent les meilleurs résultats en adoptant une stratégie de domaine centralisé pour l’authentification à travers plusieurs marques de produits ou de services. Cette stratégie offre aux utilisateurs une expérience cohérente et réduit aussi la complexité liée au déploiement et à la maintenance de plusieurs locataires Auth0 dans un environnement de production. Si vous envisagez d’avoir plusieurs domaines pour différentes marques, veuillez consulter les recommandations sur l’image de marque avant de commencer l’implémentation.
Chaque entreprise a son propre cycle de vie du développement logiciel (SDLC), et vous voudrez harmoniser votre travail avec cette stratégie tout au long du processus de développement. Par exemple, vous devez pouvoir tester votre intégration à Auth0 de la même façon que vous testez les applications elles-mêmes. Il est donc important de structurer les locataires Auth0 pour soutenir votre SDLC. Nos clients suivent généralement un modèle cohérent en ce qui concerne les pratiques exemplaires liées à l’organisation des locataires à cette fin :
Environnement
Exemple de nom de locataire
Description
Développement
company-dev
Un environnement partagé où s’effectue la majeure partie du travail de développement
AQ/Tests
company-qa ou company-uat
Un environnement destiné à la validation formelle des changements apportés
Production
company-prod
Le locataire de production
Dans certains cas, vous pourriez aussi vouloir créer une ou plusieurs zones bac à sable (p. ex., company-sandbox1, company-sandbox2) afin de tester des changements sans compromettre votre environnement de développement. C’est aussi un bon endroit pour tester des scripts de déploiement et d’autres éléments du même genre.
Vous pouvez également profiter de nos listes de vérification de mise en œuvre, que vous pouvez télécharger et personnaliser selon les besoins de votre projet de mise en œuvre.
Les clients ayant un abonnement Enterprise doivent s’assurer que les locataires configurés pour soutenir leur SDLC sont correctement liés à leur abonnement. Cela garantit que chaque locataire dispose du même ensemble de fonctionnalités activées.
Nous fournissons un guide de planification en format PDF que vous pouvez télécharger et consulter pour obtenir des précisions sur les stratégies que nous recommandons.Guide de planification du projet B2B IAM
Architecture à organisations multiples (multilocataire)
De nombreuses plateformes B2B mettent en œuvre une certaine forme d’isolement ou d’image de marque pour les organisations de leurs clients, ce qui peut complexifier tout système de gestion des identités et des accès (IAM). Si c’est votre cas, nous vous recommandons de prendre le temps de consulter nos conseils et nos pratiques exemplaires pour ce type d’environnement.Architecture à organisations multiples
Authentification
Gérer les utilisateurs
Personnaliser
Auth0 AI
Plateforme