Meilleure pratique Si vous avez plusieurs applications et avez besoin d’exploiter le SSO, nous vous recommandons de consulter notre guide de formation Comment mettre en oeuvre l’authentification unique (SSO) avant de continuer. :::
Le fait d’investir du temps dans l’architecture dès le départ s’avère payant à long terme, et un certain nombre d’éléments doivent être pris en compte lors de l’examen de la fonctionnalité et du flux de travail :- À quoi doit ressembler l’URL lorsque Auth0 doit présenter une page web à un utilisateur?
- Comment Auth0 peut-il être structuré pour soutenir 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 si d’autres projets de votre organisation s’intègrent à Auth0? En particulier les projets qui s’adressent à leur propre domaine d’utilisateurs ou à un domaine différent (par ex., les applications utilisées uniquement par les employés)?
Meilleure pratique Il n’est pas rare que les entreprises aient des exigences en matière d’identité qui concernent plusieurs communautés d’utilisateurs : clients, partenaires, employés, etc. Veillez donc à prendre en compte d’autres projets ou exigences futures lorsque vous concevez votre architecture. :::
En outre, vous disposez sans aucun doute d’un ensemble de processus et de procédures établis dans le cadre de votre cycle de vie du développement logiciel (SDLC). Vous voudrez donc consulter nos conseils de prise en charge du SDLC concernant le provisionnement du locataire Auth0 à l’appui de cela également. Pour les applications destinées aux clients, nous considérons généralement OpenID Connect (OIDC) comme étant le protocole le plus fréquemment utilisé. L’OIDC utilise des flux de travail Web avec des URL de navigateur qui sont présentés à l’utilisateur. Par défaut, les URL orientées client dans le cadre de la prise en charge OIDC d’Auth0 sont marquées Auth0. Cependant, nous recommandons d’utiliser la fonctionnalité de domaine personnalisé d’Auth0 afin d’assurer une cohérence avec l’identité de l’entreprise et de répondre aux éventuelles préoccupations de confiance des utilisateurs avant qu’elles ne surviennent.Meilleures pratiques D’autres groupes au sein de votre organisation peuvent également travailler avec Auth0; il n’est pas rare pour nos clients d’avoir des services disparates qui servent différentes communautés d’utilisateurs. L’identification de ces éléments influencera potentiellement vos choix en matière de conception, et le faire tôt pourrait atténuer les effets des décisions qui pourraient s’avérer coûteuses par la suite. :::
Provisionnement des locataires
Tout commence avec un locataire Auth0. C’est ici que vous configurez votre utilisation d’Auth0, et où les actifs Auth0, tels que les Applications, les Connexions et les profils utilisateurs, sont définis, gérés et stockés. L’accès à un locataire Auth0 se fait via Auth0 Dashboard, et via ce tableau de bord, vous pouvez également créer des locataires supplémentaires associés. Vous avez la possibilité de créer plusieurs locataires Auth0 afin de structurer vos locataires de manière à isoler différents domaines d’utilisateurs et à soutenir votre Cycle de vie de développement logiciel (SDLC).Les noms des locataires ne peuvent être modifiés ou réutilisés une fois qu’ils ont été supprimés. Assurez-vous donc que le(s) nom(s) choisi(s) vous convient(ent) avant de créer vos locataires Auth0.
Association de locataires
Pour vous assurer que vos locataires sont tous associés à votre accord contractuel Auth0 et qu’ils disposent des mêmes fonctionnalités, vérifiez que tous vos locataires sont associés à votre compte d’entreprise. Si vos développeurs souhaitent créer leurs propres bacs à sable à des fins de test, assurez-vous qu’ils sont associés à votre compte afin qu’ils disposent également des mêmes autorisations. Pour cela, vous devez communiquer avec votre représentant Auth0 ou le Centre d’assistance Auth0.Domaines personnalisés
Lorsque vous configurez votre locataire Auth0, votre URL d’accès à ce locataire sera rédigée de la manière suivante :https://yourTenant.auth0.com. Fournir un Domaine personnalisé, également appelé URL personnalisée pour votre locataire Auth0 est non seulement un facteur important pour répondre à vos exigences de personnalisation, mais, plus important encore, il vous offrira également des avantages en matière de sécurité.
- Certains navigateurs, par défaut, rendent difficile la communication dans une iFrame si vous ne disposez pas d’un domaine partagé.
- Il est plus difficile d’hameçonner votre domaine si vous avez une URL personnalisée, car l’attaquant devra également créer une URL personnalisée pour imiter le vôtre. Par exemple, avec un domaine personnalisé, vous pouvez utiliser votre propre certificat pour obtenir une «Validation étendue», ce qui rend l’hameçonnage encore plus difficile.
Vous n’avez droit qu’à un seul domaine personnalisé par locataire Auth0. En effet, un locataire dans Auth0 est censé représenter un « domaine » d’utilisateurs. Si vous avez besoin de plus d’une URL personnalisée, alors vous avez probablement plus d’un domaine d’utilisateurs et vous devez utiliser plusieurs locataires.
Meilleure pratique
Créez un domaine personnalisé (c.-à-d.CNAME) pour votre locataire Auth0 et créez-en un également dans l’environnement de développement pour vous assurer que vous avez géré le CNAME correctement. Par exemple, vous pourriez créer un CNAME qui associe login.mycompany.com à mycompany-prod.auth0.com.
Dans la quasi-totalité des cas, les clients ont obtenu les meilleurs résultats en adoptant une stratégie de domaine centralisé pour l’authentification de plusieurs marques de produits ou de services. Cette stratégie offre aux utilisateurs une interface utilisateur cohérente et atténue la complexité du déploiement et de la maintenance de plusieurs locataires Auth0 dans un environnement de production. Si vous envisagez d’avoir plusieurs domaines pour différentes marques, veuillez consulter nos conseils à propos de la Personnalisation, avant de commencer la mise en œuvre
Soutien SDLC
Chaque entreprise dispose d’une forme de cycle de vie du développement logiciel (SDLC) et, tout au long du processus de développement, il est important de s’aligner sur cette stratégie. Par exemple, vous devez être en mesure de 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 locataires Auth0 pour soutenir votre SDLC, et il existe un modèle cohérent que nos clients suivent généralement en ce qui concerne les meilleures pratiques associées à la disposition des locataires pour y parvenir :| Environnement | Exemple de nom de locataire | Description |
|---|---|---|
| Développement | company-dev | Un environnement partagé où se déroule la majeure partie de votre travail de développement |
| QA/Test | company-qa ou company-uat | Un environnement pour tester formellement les modifications que vous avez apportées |
| Production | company-prod | Le locataire de production |