> ## Documentation Index
> Fetch the complete documentation index at: https://translations.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
> Décrit les meilleures pratiques pour utiliser Auth0 afin de sécuriser vos applications multilocataires.
# Meilleures pratiques pour les applications multilocataires
La multilocation est une approche architecturale dans laquelle une seule instance logicielle s’exécute sur un serveur et est accessible à plusieurs groupes d’utilisateurs. Avec la multilocation, vous pouvez segmenter les utilisateurs ayant des caractéristiques communes en groupes et leur accorder des permissions et des niveaux d’accès distincts à votre application. Cela vous permet de créer et de maintenir des expériences adaptées à différents clients, unités d’affaires ou autres groupes d’utilisateurs définis.
Dans Auth0, la meilleure façon de mettre en œuvre la multilocation consiste à utiliser [Organisations Auth0](/docs/fr-ca/manage-users/organizations/organizations-overview). Au besoin, d’autres solutions héritées peuvent être utilisées pour répondre à des cas d’utilisation d’affaires précis. Si vous offrez un produit ou un service [business-to-business (B2B)](/docs/fr-ca/get-started/architecture-scenarios/business-to-business), configurer la multilocation pour vos utilisateurs d’affaires peut convenir à votre cas d’utilisation.
Les sections ci-dessous présentent les options offertes pour mettre en œuvre la multilocation dans Auth0.
Cet article utilise le terme d’architecture logicielle « tenant » pour désigner un groupe d’utilisateurs pouvant accéder à votre application. Lorsqu’il est question de votre instance Auth0, le terme « tenant Auth0 » est utilisé.
## Auth0 Organizations
Pour la plupart des cas d’utilisation multilocataires, Auth0 Organizations est la solution idéale pour vous et vos utilisateurs. Auth0 Organizations prend en charge les implémentations interentreprises (B2B) comprenant une ou plusieurs applications auxquelles les utilisateurs finaux peuvent accéder.
Les caractéristiques courantes des implémentations B2B comprennent :
* Un produit concédé sous licence à une autre entreprise pour être utilisé par ses employés.
* Plusieurs organisations qui nécessitent leur propre fédération et une personnalisation légère de l’expérience d’authentification à leur image de marque.
* Des niveaux d’accès à l’application distincts pour différents groupes d’utilisateurs.
Avec Auth0 Organizations, vous pouvez créer des groupes d’utilisateurs distincts et adapter leur expérience à l’aide du [contrôle d’accès basé sur les rôles](/docs/fr-ca/manage-users/access-control/rbac), de [pages de connexion et de modèles de courriel personnalisés](/docs/fr-ca/manage-users/organizations/create-first-organization#customize-prompts-and-email-templates), et plus encore.
Pour en savoir plus sur l’utilisation d’Auth0 Organizations pour mettre en œuvre une architecture multilocataire, consultez [Architecture à organisations multiples](/docs/fr-ca/get-started/architecture-scenarios/multiple-organization-architecture).
## Solutions héritées
Si Auth0 Organizations ne répond pas aux exigences de votre cas d’utilisation, vous pouvez envisager les solutions héritées décrites ci-dessous. Pour obtenir de l’aide afin de choisir l’approche la mieux adaptée à vos besoins particuliers, veuillez communiquer avec notre équipe des [Professional Services](/docs/fr-ca/get-started/professional-services).
Les solutions héritées comprennent :
* Utiliser une connexion Auth0 pour représenter chaque tenant.
* Utiliser une application Auth0 pour représenter chaque tenant.
* Utiliser un tenant Auth0 pour représenter chaque tenant.
* Stocker les détails du tenant dans le profil de l’utilisateur.
### Utiliser les connexions Auth0
Des limites d’entités peuvent s’appliquer. Pour en savoir plus, consultez la [politique sur les limites d’entités](/docs/fr-ca/troubleshoot/customer-support/operational-policies/entity-limit-policy). Si vous avez un abonnement Enterprise, vous ne serez pas limité en raison des limites d’entités, mais vous pourriez l’être par une connexion qui compte déjà des milliers de clients activés.
Vous pouvez représenter chacun de vos tenants par une connexion Auth0 distincte.
Cette approche vous permet de prendre en charge des scénarios où :
* Vous avez, pour chacun de vos tenants, des exigences différentes au niveau de la connexion, comme des politiques de mot de passe distinctes.
* Vous avez des ensembles d’utilisateurs provenant de connexions différentes. Par exemple, un tenant pourrait exiger que les utilisateurs fournissent un nom d’utilisateur et un mot de passe, tandis qu’un autre pourrait exiger qu’ils se connectent par l’intermédiaire d’un IdP d’entreprise.
Pour inviter un utilisateur à se connecter au moyen d’une connexion précise, effectuez une requête au [point de terminaison de connexion de l’Auth0 Authentication API](https://auth0.com/docs/api/authentication#login) et incluez le paramètre `connection`.
Si vous utilisez [Lock](/docs/fr-ca/libraries#lock) dans votre application, notez qu’il prend en charge un maximum de 50 connexions de base de données par application. Les connexions Social et Enterprise ne sont pas touchées par cette limite, mais elles demeurent assujetties à la [politique sur les limites d’entités](/docs/fr-ca/troubleshoot/customer-support/operational-policies/entity-limit-policy).
### Utiliser des applications Auth0
Des limites d’entités peuvent s’appliquer. Pour en savoir plus, consultez la [Politique sur les limites d’entités](/docs/fr-ca/troubleshoot/customer-support/operational-policies/entity-limit-policy). Si vous avez un abonnement Enterprise, vous ne serez pas limité par les limites d’entités, mais vous pourriez l’être par une connexion qui a déjà des milliers de clients activés.
Vous pouvez représenter chacun de vos tenants par une application Auth0 distincte.
Cette approche vous permet de configurer chaque application Auth0 de manière unique selon les exigences propres à chaque tenant, comme les connexions disponibles.
Vous devrez faire le suivi des tenants auxquels appartiennent vos utilisateurs dans votre application. Lorsqu’un utilisateur ouvre une session dans votre application, vous devrez lire cette information et diriger l’utilisateur vers l’application Auth0 appropriée pour terminer l’authentification.
Pour activer une connexion pour plusieurs applications avec la Management API d’Auth0, effectuez une requête à l’[endpoint Update enabled clients for a connection](https://auth0.com/docs/api/management/v2/connections/patch-clients) et transmettez l’ID de connexion approprié.
### Utiliser des tenants Auth0
Vous pouvez représenter chacun de vos tenants par un tenant Auth0 distinct.
Cette approche vous permet de partager l’accès au Auth0 Dashboard avec des utilisateurs, en limitant cet accès par tenant, mais elle exige que vous configuriez Auth0 séparément pour chaque tenant.
Cela signifie qu’en plus de gérer séparément les fonctionnalités de chaque tenant Auth0 (comme Branding, Actions et Attack Protection), votre application devra prendre en charge plusieurs configurations Auth0.
### Stocker les détails du tenant dans le profil de l'utilisateur
Vous pouvez stocker les détails du tenant dans le profil de l'utilisateur et faire en sorte que votre application lise ces informations une fois que l'utilisateur s'est connecté.
Cette approche permet à tous vos utilisateurs, quel que soit le tenant auquel ils appartiennent, de se connecter à l'aide d'une configuration uniforme (comme les connexions disponibles).
Pour ce faire, vous pouvez stocker les détails du tenant dans le profil Auth0 de l'utilisateur, dans l'[objet `app_metadata`](/docs/fr-ca/manage-users/user-accounts/metadata), en utilisant un identifiant de votre choix (par exemple, `"tenant": "customer-group-12345"`). Une fois l'utilisateur connecté, votre application récupère la variable `tenant`, puis affiche une version adaptée à la valeur renvoyée.