Skip to main content
Comprendre votre est essentiel pour comprendre comment Auth0 peut être mis à profit pour répondre à vos besoins. D’après notre expérience, les clients qui réussissent le mieux commencent par une visualisation de l’architecture proposée — ou, dans bien des cas, existante — et s’en servent comme point de référence à mesure qu’ils avancent. Il est aussi important de comprendre où votre application s’inscrit dans votre organisation; les Accounts and Tenants d’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 profiter du Single Sign-On (SSO), d’une gestion centralisée des profils, d’une facturation consolidée, ou d’éléments du même genre.
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, d’après notre expérience, un effort qui porte ses fruits à long terme. Voici donc quelques éléments à prendre en considération lorsque vous examinez les fonctionnalités et le flux de travail :
  • À quoi l’URL devrait-elle ressembler lorsqu’Auth0 doit présenter une page web à un utilisateur ?
  • Comment Auth0 peut-il être structuré pour prendre en charge votre SDLC (Software Development Lifecycle) ?
  • Comment pouvez-vous vous assurer que vos tenants Auth0 sont correctement associés à votre contrat ?
  • Que devez-vous prendre en considération 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 que seuls les employés utiliseront) ?
couvrent souvent plus d’un domaine d’utilisateurs — clients, employés et affiliés étant les cas les plus fréquents, 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 segmenter davantage à l’intérieur d’un même domaine — par exemple, des 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 éléments connexes, et la section provisionnement du tenant traite cela plus en détail. Si vous devez provisionner un indépendant, vous voudrez aussi l’associer à votre compte Auth0 existant, afin de profiter pleinement des avantages offerts par le niveau de 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 lorsque vous concevez votre architecture.
De plus, vous avez sans doute déjà un ensemble établi de processus et de procédures dans le cadre de votre Software Development Lifecycle (SDLC). Vous voudrez donc aussi consulter nos conseils sur la prise en charge du SDLC relativement au provisionnement du tenant d’Auth0. Pour les applications destinées aux clients, nous constatons généralement qu’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’OIDC par Auth0 portent l’image de marque d’Auth0; toutefois, nous recommandons d’utiliser la fonctionnalité de domaine personnalisé d’Auth0 afin d’assurer une identité d’entreprise cohérente et de répondre aux éventuelles préoccupations des utilisateurs en matière de confiance avant qu’elles ne se posent.
D’autres groupes au sein de votre organisation utilisent peut-être aussi Auth0; il n’est pas rare que nos clients aient des départements distincts au service de différentes communautés d’utilisateurs. Les identifier pourrait 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 du tenant

Tout commence par un tenant Auth0. C’est là que vous configurerez votre utilisation d’Auth0 et que les ressources Auth0, comme les Applications, les Connections et les profils utilisateur, sont définies, gérées et stockées. L’accès à un tenant Auth0 se fait au moyen du Dashboard Auth0, et à partir du Dashboard, vous pouvez aussi créer d’autres tenants associés; vous pouvez créer plus d’un tenant Auth0 afin de structurer vos tenants 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 tenant ne peuvent pas être modifiés ni réutilisés une fois supprimés. Assurez-vous donc d’être satisfait de votre ou de vos noms avant de créer vos tenants Auth0.
Déterminer le niveau d’isolation requis pour vos domaines d’utilisateurs est une étape importante et, combiné à vos exigences en matière d’image de marque, vous aidera ensuite à déterminer le nombre de tenants Auth0 nécessaires dans votre environnement de production. Comme nous vous recommandons de créer une suite complète de tenants prenant en charge le SDLC pour chaque tenant Auth0 que vous exploiterez dans un environnement de production, le nombre de tenants Auth0 à gérer peut rapidement augmenter. Vous devriez donc réfléchir attentivement avant de créer plusieurs tenants Auth0 pour la production et consulter nos conseils sur l’image de marque avant de prendre votre décision finale.

​
Association de tenant

Pour vous assurer que vos tenants sont tous associés à votre entente contractuelle avec Auth0 et qu’ils offrent les mêmes fonctionnalités, assurez-vous que tous vos tenants sont associés au compte de votre entreprise. Si certains développeurs souhaitent créer leurs propres sandboxes pour faire des tests, assurez-vous qu’ils sont eux aussi associés à votre compte afin d’avoir les mêmes autorisations. Pour ce faire, communiquez avec votre représentant Auth0 ou le Auth0 Support Center.

​
Domaines personnalisés

Lorsque vous configurez votre tenant Auth0, l’URL pour accéder à ce tenant sera de la forme https://yourTenant.auth0.com. Fournir un Custom Domain (aussi appelé URL vanity) pour votre tenant Auth0 n’est pas seulement un élément important pour répondre à vos exigences d’image de marque, mais vous procure aussi, et surtout, des avantages en matière de sécurité :
Vous ne pouvez avoir qu’un seul domaine personnalisé par tenant Auth0. En effet, dans Auth0, un tenant est conçu pour 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 tenants.
Votre nom de 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épart afin de vous assurer d’effectuer 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 tenant 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 pointer login.mycompany.com vers mycompany-prod.auth0.com.
Dans presque tous les cas, les clients ont obtenu les meilleurs résultats en adoptant une stratégie de domaine centralisé pour l’authentication couvrant plusieurs images de marque 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 tenants Auth0 dans un environnement de production. Si vous envisagez d’avoir plusieurs domaines pour différentes images de marque, veuillez consulter les directives 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 vous voudrez harmoniser votre démarche avec cette stratégie tout au long du processus de développement. Par exemple, vous devez pouvoir tester votre intégration avec Auth0 de la même manière que vous testez les applications elles-mêmes. Il est donc important de structurer les tenants Auth0 pour soutenir votre SDLC. Nos clients suivent généralement un modèle uniforme en ce qui a trait aux bonnes pratiques d’organisation des tenants : Dans certains cas, vous pourriez aussi vouloir créer un ou plusieurs sandboxes (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 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.

​
Guide de planification de projet

Nous mettons à votre disposition un guide de planification en format PDF que vous pouvez télécharger et consulter pour en savoir plus sur les stratégies que nous recommandons. Guide de planification de projet B2C IAM