Architecture (B2B)

Il est essentiel de bien connaître votre application pour savoir comment Auth0 peut répondre à vos besoins. Par expérience, nos clients les plus performants commencent par une visualisation de leur projet d’architecture - ou, dans de nombreux cas, de leur architecture existante - et l’utilisent comme base de référence au fur et à mesure qu’ils progressent. Il est également important de comprendre la place de votre application au sein de votre organisation; Comptes et locataires Auth0 constitue la base du regroupement et de la structuration des actifs Auth0, et il se peut que vous deviez tirer parti d’un déploiement Auth0 existant afin de l’intégrer à l’authentification unique (SSO), à la gestion centralisée des profils d’utilisateur, à la facturation consolidée ou à d’autres éléments de ce type.

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?

Les organisations desservent souvent plus d’un domaine d’utilisateurs - les clients, les employés et les affiliés étant les plus fréquemment rencontrés, avec généralement peu ou pas de croisement : les employés, par exemple, n’utilisent pas les mêmes applications que les clients et vice-versa. Dans certains cas, il peut également s’avérer nécessaire de procéder à une partition plus poussée au sein d’un domaine - des groupes de clients distincts, par exemple, qui utilisent des produits différents et sans lien entre eux. Auth0 fournit un moyen de séparer vos utilisateurs et les garanties associées, et la fourniture de locataire couvre cela plus en détail. Si vous avez besoin de fournir un locataire indépendant, vous voudrez également l’associer à votre compte Auth0 existant, afin que vous puissiez profiter pleinement des avantages fournis au niveau de l’abonnement choisi par votre organisation.

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.

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.

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).

Déterminer le niveau d’isolation dont vous avez besoin pour vos domaines d’utilisateurs est une étape importante qui, avec vos exigences en matière de personnalisation, vous aidera par la suite à déterminer le nombre de locataires Auth0 nécessaires dans votre environnement de production. Comme nous vous recommandons de créer une suite complète de locataires prenant en charge le SDLC pour chaque locataire Auth0 que vous exécuterez dans un environnement de production, le nombre de locataires Auth0 que vous devrez gérer peut rapidement augmenter. C’est pourquoi vous devez bien réfléchir avant de créer plusieurs locataires Auth0 pour la production, et consulter nos conseils sur l’Personnalisation avant de prendre votre décision finale.

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.

Dans ces deux cas, nous vous recommandons de créer un locataire Auth0 distinct pour chaque organisation qui répond à l’un des critères ci-dessus.

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.

Lorsque vous configurez votre locataire Auth0, l’URL permettant d’accéder à ce locataire sera de la forme https://{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.

Votre nom de domaine personnalisé doit également donner à l’utilisateur l’assurance qu’il s’agit de l’endroit approprié pour saisir ses informations d’identification. Nous vous recommandons de créer votre domaine personnalisé dans tous les environnements le plus tôt possible afin de vous assurer que les tests se déroulent de manière cohérente d’un environnement à l’autre. Il est extrêmement important d’apprendre à vos utilisateurs à rechercher des URL suspectes lorsqu’ils saisissent leurs identifiants.

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.

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 :

Dans certains cas, vous pouvez également vouloir créer un ou plusieurs bacs à sable (« sandbox ») (p. ex., company-sandbox1, company-sandbox2) afin de pouvoir tester les changements sans compromettre votre environnement de développement. Il peut s’agir de l’emplacement où vous testez les scripts de déploiement, etc.

Nous fournissons un guide de planification en format PDF que vous pouvez télécharger; vous pouvez vous y référer pour de plus amples détails concernant nos stratégies recommandées.

Plusieurs plateformes mettent en œuvre une forme d’isolation et/ou d’image de marque pour les organisations de leurs clients, ce qui peut ajouter de la complexité à tout système de Gestion des identités et des accès (IAM). Si cela s’applique à vous, nous vous conseillons de prendre le temps de lire nos conseils et bonnes pratiques pour ce type d’environnement.

Architecture à organisations multiples