Passer au contenu principal
Comprendre votre est essentiel pour voir comment Auth0 peut répondre à vos besoins. D’après notre expérience, nos clients qui obtiennent le plus de succès commencent par visualiser leur architecture prévue — ou, dans bien des cas, existante — et s’y réfèrent ensuite tout au long de leur progression. Il est également important de comprendre où votre application s’inscrit 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 l’authentification unique (SSO), la gestion centralisée des profils, la facturation consolidée, ou des fonctionnalités semblables.
Si vous avez plusieurs applications et que vous devez tirer parti du SSO, nous vous recommandons de consulter d’abord 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 qui porte ses fruits à long terme. Voici quelques éléments à prendre en compte lorsque vous évaluez les fonctionnalités et le flux de travail :
  • À quoi l’URL doit-elle ressembler lorsqu’Auth0 doit présenter une page Web à un utilisateur ?
  • Comment Auth0 peut-il être structuré pour prendre en charge votre cycle de vie du développement logiciel (SDLC) ?
  • Comment pouvez-vous vous assurer que vos locataires Auth0 sont correctement associés à votre contrat ?
  • Que devez-vous prendre en compte s’il existe d’autres projets dans votre organisation qui s’intègrent à Auth0 ? En particulier, les projets qui ciblent leur propre domaine d’utilisateurs, ou un domaine d’utilisateurs différent (par exemple, des applications utilisées uniquement par des employés) ?
desservent souvent plus d’un domaine d’utilisateurs — clients, employés et 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 au sein d’un domaine — par exemple, des groupes distincts de clients qui utilisent des produits différents et sans lien entre eux. Auth0 fournit un moyen de séparer vos utilisateurs et les ressources associées, et le provisionnement du locataire traite de ce sujet plus en détail. Si vous devez provisionner un indépendant, vous voudrez aussi l’associer à votre compte Auth0 existant, afin de pouvoir tirer pleinement parti des avantages offerts au niveau de l’ de votre organisation.
Il n’est pas rare que les entreprises aient des exigences en matière d’identité qui couvrent plusieurs communautés d’utilisateurs : clients, partenaires, employés, etc. Assurez-vous donc de tenir compte des autres projets ou des besoins futurs lors de la conception de votre architecture.
De plus, vous avez sans doute déjà 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 directives sur la prise en charge du SDLC concernant le provisionnement des locataires Auth0 à cet égard. Pour les applications destinées aux clients, nous constatons généralement que OpenID Connect (OIDC) est le protocole le plus souvent utilisé. OIDC s’appuie 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’Auth0 pour OIDC portent la marque Auth0; toutefois, nous recommandons d’utiliser la fonctionnalité de domaine personnalisé d’Auth0 afin d’assurer une identité de marque cohérente et de répondre aux préoccupations potentielles des utilisateurs en matière de confiance avant même qu’elles ne se présentent.
D’autres groupes au sein de votre organisation peuvent aussi travailler avec Auth0 ; il n’est pas rare que nos clients aient des services distincts qui répondent aux besoins de différentes communautés d’utilisateurs. Les identifier peut influencer vos choix de conception, et le faire tôt peut vous éviter de prendre des décisions qui pourraient s’avérer coûteuses par la suite.

Provisionnement d’un locataire

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 utilisateur, sont définies, gérées et stockées. L’accès à un locataire Auth0 se fait au moyen du Dashboard Auth0. À partir du Dashboard, vous pouvez aussi créer d’autres locataires 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 d’être satisfait de vos noms avant de créer vos locataires Auth0.
Déterminer le niveau d’isolation dont vous avez besoin pour vos domaines d’utilisateurs est une étape importante et, combiné à vos exigences en matière d’image de marque, cela vous aidera ensuite à déterminer le nombre de locataires Auth0 requis dans votre environnement de production. Comme nous vous recommandons de créer un ensemble complet de locataires prenant en charge le SDLC pour chaque locataire Auth0 que vous exploiterez 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 conseils sur l’image de marque avant de prendre votre décision finale.

Association des locataires

Pour vous assurer que vos locataires sont tous associés à votre entente contractuelle avec Auth0 et qu’ils disposent des mêmes fonctionnalités, veillez à ce que tous vos locataires soient associés à votre compte d’entreprise. Si certains de vos développeurs souhaitent créer leurs propres bacs à sable, assurez-vous qu’ils soient également associés à votre compte afin qu’ils disposent eux aussi des mêmes autorisations. Pour ce faire, communiquez avec votre représentant Auth0 ou le Centre de soutien Auth0.

Domaines personnalisés

Lorsque vous configurez votre locataire Auth0, l’URL d’accès à ce locataire est de la forme https://yourTenant.auth0.com. Fournir un domaine personnalisé (aussi appelé URL personnalisée) pour votre locataire Auth0 n’est pas seulement un élément important pour répondre à vos besoins en image de marque, mais surtout, cela vous procure aussi des avantages sur le plan de la sécurité :
Un seul domaine personnalisé est autorisé par locataire Auth0. Cela s’explique par le fait qu’un locataire dans Auth0 est censé représenter un « domaine » d’utilisateurs. Si vous avez besoin de plus d’une URL personnalisée, vous avez probablement plus d’un domaine d’utilisateurs et devriez utiliser plusieurs locataires.
Le nom de votre domaine personnalisé devrait aussi inspirer confiance à l’utilisateur en lui indiquant qu’il s’agit du bon endroit où saisir ses identifiants. Nous vous recommandons également de créer votre domaine personnalisé dès le départ dans tous les environnements 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. un CNAME) pour votre locataire Auth0, et créez-en aussi un dans l’environnement de développement afin de vous assurer que vous avez correctement configuré le CNAME. Par exemple, vous pourriez créer un CNAME qui associe 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 à l’échelle de 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, consultez les recommandations sur l’image de marque avant de commencer la mise en œuvre.

Prise en charge du SDLC

Chaque entreprise a son propre cycle de vie du développement logiciel (SDLC), et, tout au long du processus de développement, vous voudrez harmoniser votre approche avec cette stratégie. Par exemple, vous devez pouvoir tester votre intégration avec 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 :
EnvironnementExemple de nom de locataireDescription
Développementcompany-devUn environnement partagé où s’effectue la majeure partie du travail de développement
AQ/testscompany-qa ou company-uatUn environnement destiné aux tests formels des changements apportés
Productioncompany-prodLe locataire de production
Dans certains cas, vous pourriez aussi vouloir créer un ou plusieurs bacs à sable (p. ex., company-sandbox1company-sandbox2) afin de tester des changements sans compromettre votre environnement de développement. C’est aussi souvent là que vous testerez des scripts de déploiement et d’autres éléments semblables.
Vous pouvez aussi tirer parti de nos listes de vérification d’implémentation, que vous pouvez télécharger et personnaliser selon les besoins de votre projet d’implémentation.

Guide de planification du projet

Nous mettons à votre disposition un guide de planification en format PDF que vous pouvez télécharger et consulter pour obtenir plus de détails sur nos stratégies recommandées. Guide de planification du projet IAM B2C