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)?
- Comment pouvez-vous aligner la structure et le domaine de l’organisation de vos clients avec votre déploiement Auth0?
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 soutien SDLC concernant la fourniture locataire d’Auth0 à l’appui de cela aussi. Pour les applications orientées client, nous constatons généralement que OpenID Connect (OIDC) est 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. Dans le cadre de la prise en charge d’Auth0 OIDC, les URL orientées client sont de marque Auth0, mais nous recommandons d’utiliser la fonctionnalité domaine personnalisé d’Auth0 afin de garantir une identité d’entreprise cohérente et de répondre aux problèmes potentiels de confiance des utilisateurs avant qu’ils ne se posent.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. :::
Si certaines ou toutes les organisations de vos clients ont besoin de leur propre URL personnalisée, ou si elles utilisent des fournisseurs de médias sociaux qui ont besoin d’une page de consentement personnalisée à la marque de l’organisation, nous vous recommandons de créer des locataires Auth0 distincts pour ces organisations; voir Fourniture de locataires pour les organisations complexes pour plus de détails.Provisionnement des locataires
Tout commence avec un locataire Auth0. C’est là que vous configurerez votre utilisation d’Auth0 et que les actifs Auth0, tels qu’applications, connexions et profils utilisateurs, sont définis, gérés et stockés. L’accès à un locataire Auth0 s’effectue à partir de l’Auth0 Dashboard, qui vous permet également de créer des locataires supplémentaires associés. Vous êtes autorisé à créer plus d’un locataire Auth0 afin de structurer vos locataires de manière à isoler différents domaines d’utilisateurs et à prendre en charge 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.
Provisionnement des locataires pour les 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 facile avec la sortie de notre nouvelle fonctionnalité Organizations (Organisations). Toutefois, dans certaines circonstances, cette fonctionnalité peut s’avérer utile pour réduire la complexité de votre installation. Par exemple, nous recommandons de provisionner un locataire Auth0 distinct pour l’organisation de vos clients comme bonne pratique si :- Vos organisations clientes nécessitent une URL de connexion personnalisée qui est propre à l’organisation. C’est généralement le cas uniquement si vous permettez à vos organisations de disposer de leur propre URL personnalisée au lieu d’utiliser une URL de connexion commune. Auth0 prend en charge un domaine personnalisé par locataire.
- Vos organisations clientes utilisent des fournisseurs sociaux pour se connecter. Dans ce cas, il est souvent souhaitable que l’organisation dispose d’une page de consentement personnalisée destinée au fournisseur social et portant la marque de son organisation.
La gestion de plusieurs locataires Auth0 peut rajouter de la complexité à votre système et ne doit être effectuée qu’en cas de nécessité absolue.
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, assurez-vous 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 ce faire, vous devez contacter votre représentant Auth0 ou le Centre d’assistance Auth0.Domaines personnalisés
Lorsque vous configurez votre locataire Auth0, l’URL permettant d’accéder à ce locataire sera de la formehttps://{yourTenant}.auth0.com
. Fournir un Domaine personnalisé (également connu sous le nom d’URL de redirection vers un microsite), pour votre locataire Auth0 n’est pas seulement un facteur important pour soutenir vos exigences en matière d’image de marque, mais plus important encore, il vous apportera également des avantages en matière de sécurité :
- Certains navigateurs rendent, par défaut, la communication difficile dans une iFrame si vous n’avez pas de 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 vous référer au guide Image de marque 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 le cycle de vie du développement logiciel, et notre clientèle suit généralement un modèle cohérent de meilleures pratiques associées à la configuration des locataires :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 |
Meilleure pratique
Vous pouvez également tirer parti de nos Listes de contrôle de mise en œuvre que vous pouvez télécharger et personnaliser pour répondre aux besoins de votre projet de mise en œuvre.Les clients ayant souscrit un abonnement Enterprise doivent s’assurer que les locataires mis en place pour prendre en charge leur SDLC sont correctement associés à leur abonnement. Cela permettra de s’assurer que chaque locataire dispose d’un ensemble cohérent de fonctionnalités activées.