> ## Documentation Index > Fetch the complete documentation index at: https://auth0.com/llms.txt > Use this file to discover all available pages before exploring further. # Fournisseur d’identité unique : Autorisation > Apprenez à autoriser les utilisateurs pour les organisations dans les architectures multilocataires. Pour ce qui est de l’autorisation, vous devez généralement réfléchir à la manière dont vous déterminez ce qu’une personne est autorisée à faire et à la manière dont vous communiquez ces informations à vos applications et/ou à vos API. Selon les applications que vous utilisez, vous pouvez être concerné par l’un de ces problèmes, ou même les deux. Dans nos scénarios d’architecture, nous fournissons des orientations générales sur [l’autorisation B2B](/docs/fr-ca/get-started/architecture-scenarios/business-to-business/authorization), que nous recommandons d’examiner en même temps que les orientations fournies ici. * Les [jetons d’ID](/docs/fr-ca/secure/tokens/id-tokens) sont souvent utilisés pour transmettre des informations sur l’autorisation de l’utilisateur aux applications par le biais de demandes personnalisées, qui peuvent être ajoutées grâce à l’extensibilité des [Règles](/docs/fr-ca/customize/rules). Les demandes ajoutées vous permettent de présenter une interface utilisateur dans laquelle les utilisateurs n’ont pas la possibilité de tenter une action non autorisée. Les informations d’autorisation contenues dans un jeton d’ID fournissent également à toute application dorsale un moyen d’empêcher les utilisateurs de contourner les contrôles du côté client pour les applications web traditionnelles. **Meilleure pratique** Vous pouvez tirer parti du [contrôle d’accès basé sur les rôles (RBAC) Auth0](/docs/fr-ca/manage-users/access-control/rbac) via la fonctionnalité [Auth0 Authorization Core](/docs/fr-ca/manage-users/access-control/configure-core-rbac) pour définir les autorisations d’accès, qui peuvent être automatiquement appliquées aux jetons d’accès. Pour en savoir plus, consultez [Activer le contrôle d’accès basé sur les rôles pour les API](/docs/fr-ca/get-started/apis/enable-role-based-access-control-for-apis). La fonctionnalité RBAC d’Auth0 peut également fournir des informations que vous pouvez ajouter en tant que demandes personnalisées aux jetons d’ID (et aux jetons d’accès, si vous préférez une application manuelle). Les organisations Auth0 peuvent exploiter la fonctionnalité RBAC d’Auth0 via un ou plusieurs rôles attribués aux membres. Pour en savoir plus, consultez [Ajout de rôles aux membres d’une organisation](/docs/fr-ca/manage-users/organizations/configure-organizations/add-member-roles). * Les API qui fournissent un accès public à des services de ressources partagées sont généralement protégées par des mécanismes de contrôle d’accès. À cette fin, Auth0 permet de créer un jeton porteur d’autorisation, ou [jeton d’accès](/docs/fr-ca/manage-users/organizations/configure-organizations/add-member-roles) OAuth 2, qui peut transmettre des informations sur l’autorisation de l’utilisateur à une API, généralement en utilisant le [contrôle d’accès basé sur les rôles (RBAC)](/docs/fr-ca/manage-users/access-control/configure-core-rbac) pour appliquer [un ou plusieurs rôles attribués en fonction de l’appartenance](/docs/fr-ca/secure/tokens/access-tokens) ou en ajoutant des demandes personnalisées via l’extensibilité des [Règles](/docs/fr-ca/customize/rules). Vous pouvez également exploiter la capacité RBAC d’Auth0 pour ajuster automatiquement la demande de `permission` d’un jeton d’accès. Les API peuvent alors utiliser ces informations pour appliquer le niveau approprié de contrôle d’accès, ce qui permet à votre API d’appliquer les règles de stratégie sans avoir à effectuer une recherche supplémentaire pour obtenir des informations sur l’utilisateur. * Dans certains cas, vous pouvez implémenter des stratégies au niveau de l’application dans le locataire Auth0, ce qui vous permet d’appliquer des stratégies à toute une série d’applications et de services de ressources (API) sans avoir à modifier chacun d’entre eux de manière indépendante. Vous mettez généralement cela en œuvre par le biais de l’extensibilité des [Règles](/docs/fr-ca/customize/rules). **Meilleure pratique** Auth0 Organizations fournit des règles d'Auth0 avec accès à des informations centrées sur l’organisation qui peuvent être consultées lors de l’authentification d’un utilisateur. Ces informations sont disponibles via l’objet `organization` contenu dans l’objet contextuel `Rules` (règles). L’objet `organization` permet également d’accéder à toutes les métadonnées fournies pour une définition Organization dans Auth0. Pour en savoir plus, consultez [Développement personnalisé pour les organisations](/docs/fr-ca/manage-users/organizations/custom-development). ## Demandes relatives aux jetons d’ID En général, les demandes peuvent être ajoutées aux jetons d’ID, comme indiqué dans notre guide des meilleures pratiques en matière de [demandes de jetons d’ID](/docs/fr-ca/get-started/architecture-scenarios/business-to-consumer/authorization). Lorsque vous utilisez la fonctionnalité Auth0 Organizations, une demande `org_id` est automatiquement ajoutée à tout jeton d’ID (pour un exemple, consulter [Travailler avec des jetons et Organizations](/docs/fr-ca/manage-users/organizations/using-tokens)) émis pour les utilisateurs membres d’une organisation. Ce paramètre est validé par les trousses SDK Auth0. Vous pouvez également ajouter des informations supplémentaires associées à une organisation Auth0 en ajoutant une demande personnalisée au jeton d’ID : ```javascript lines theme={null} context.idToken['http://travel0.net/multifactor'] = context.multifactor; ``` **Remarque** : Si vous avez configuré votre locataire pour qu’il prenne en charge les noms d’organisation dans Authentication API, la demande `org_name` est automatiquement incluse dans les jetons d’ID. Pour en savoir plus, consultez [Utiliser des noms d’organisation dans la Authentication API](/docs/fr-ca/manage-users/organizations/configure-organizations/use-org-name-authentication-api). ### Affirmation SAML Bien que la fonction Auth0 Organization ne prenne pas en charge les applications SAML, une affirmation SAML générée par un fournisseur d’identités (IdP) en amont peut être configurée pour alimenter des demandes standard ou personnalisées dans un jeton d’ID consommé en aval. Par exemple, vous pouvez définir la section Mappages d’une connexion d’entreprise SAML : ```json lines theme={null} { "user_id": [ "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn", "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name" ], "email": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress", "name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name", "given_name": [ "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname", "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name" ], "family_name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname", "groups": "http://schemas.xmlsoap.org/claims/Group" } ``` Dans cet exemple, chaque champ se verra attribuer une valeur dans l’objet `user` d’une Règle, qui correspondra aux demandes standard d’un jeton d’ID ou pourra être mis en correspondance à l’aide de demandes personnalisées. Pour en savoir plus sur la personnalisation des mappages SAML, consulter [Connecter votre application aux fournisseurs d’identité SAML : Configurer les mappages](/docs/fr-ca/connections/enterprise/saml#set-up-mappings). ## Demandes relatives au jeton d’accès En plus des autres demandes que vous ajoutez à votre jeton d’accès pour les décisions de contrôle d’accès (voir notre guide général des meilleures pratiques [Demandes liées au jeton d’accès](/docs/fr-ca/get-started/architecture-scenarios/business-to-consumer/authorization)), vous voudrez généralement communiquer l’organisation à laquelle l’utilisateur appartient. Comme pour le jeton d’ID, lorsque vous utilisez la fonctionnalité Auth0 Organizations, la demande `org_id` est automatiquement ajoutée à tout jeton d’accès (pour un exemple, voir [Travailler avec des jetons et Organizations](/docs/fr-ca/manage-users/organizations/using-tokens)) émis pour les utilisateurs membres d’une organisation. Vous pouvez également ajouter des informations supplémentaires associées à une organisation Auth0 en ajoutant une demande personnalisée au jeton d’accès : ```javascript lines theme={null} context.accessToken['http://travel0.net/multifactor'] = context.multifactor; ``` **Remarque** : Si vous avez configuré votre locataire pour qu’il prenne en charge les noms d’organisation dans Authentication API, la demande `org_name` est automatiquement incluse dans les jetons d’accès. Pour en savoir plus, consultez [Utiliser des noms d’organisation dans la Authentication API](/docs/fr-ca/manage-users/organizations/configure-organizations/use-org-name-authentication-api). Vous pouvez également créer une audience API unique pour chaque organisation, ce qui donnera lieu à une définition API unique dans Auth0. Bien que ce mécanisme puisse atténuer la nécessité d’utiliser l’extensibilité des Règles personnalisées, sa complexité peut représenter un défi. Voici une comparaison simple : | Approche | Avantages | Inconvénients | | --------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Public API unique | | | | Demande Personnalisée | Simplifie la configuration du locataire Auth0. Code personnalisé nécessaire dans une règle pour ajouter l’organisation au jeton d’accès. | | ### Rôles La fonction Auth0 Organizations prend également en charge le [Contrôle d’accès basé sur les rôles (RBAC)](/docs/fr-ca/manage-users/access-control/rbac) par l’intermédiaire de la fonction [Authorization Core](/docs/fr-ca/manage-users/access-control/configure-core-rbac) associée à un locataire Auth0. Le contrôle d’accès basé sur les rôles est [appliqué au niveau Auth0 Organization](/docs/fr-ca/manage-users/organizations/configure-organizations/add-member-roles). Vous pouvez [activer Auth0 Authorization Core RBAC pour une API](/docs/fr-ca/get-started/apis/enable-role-based-access-control-for-apis), ce qui entraînera l’activation de la demande de `permission` par défaut dans des jetons d’accès en cours de modification automatique et l’ajout d’une demande `d’autorisation` par défaut (pour obtenir un exemple, consultez [Travailler avec des jetons et Organizations](/docs/fr-ca/manage-users/organizations/using-tokens)). Vous pouvez également ajouter des informations sur les rôles aux jetons d’ID en tant que demandes personnalisées en accédant à l’objet `d’autorisation` disponible dans l’objet `context` des règles. Pour en savoir plus, consultez [Règles avec autorisation - Exemples de cas d’utilisation : Ajouter des rôles d’utilisateur aux jetons](/docs/fr-ca/manage-users/access-control/sample-use-cases-rules-with-authorization). ## Contrôle d’accès L’application de la stratégie au niveau des ressources relève de la responsabilité des applications et/ou des API de votre système. Si vous tentez d’appliquer des stratégies dans un serveur d’autorisation centralisé, comme votre locataire Auth0, vous vous heurterez rapidement à un système de contrôle complexe, difficile à maintenir et à appréhender. Au lieu de cela, votre serveur d’autorisation centralisé peut s’assurer que les informations appropriées sur un utilisateur sont incluses dans les jetons, de sorte que vos applications et API disposent des informations nécessaires pour prendre des décisions en matière d’application des stratégies. À tout le moins, dans les situations où les informations sont trop volumineuses pour être contenues dans un seul jeton (par exemple, les autorisations au niveau des ressources) ou lorsque les informations changent assez fréquemment pour être périmées si l’on y accède directement dans le jeton, vos applications et vos API devraient être en mesure de rechercher les informations correctes. En revanche, l’application de certaines stratégies de haut niveau peut être gérée de manière centralisée. Par exemple, lorsque vous utilisez un contexte Locataire Auth0, vous pouvez, dans certaines situations, implémenter une règle qui atténue la nécessité pour chaque application et/ou l’API d’appliquer les mêmes restrictions. Il s’agit notamment de : * bloquer l’accès aux utilisateurs à partir d’une adresse IP particulière; * implémenter des exigences spécifiques en matière d’authentification multifacteur contextuelle ou adaptative; * limiter la connexion aux seuls utilisateurs ayant vérifié leur adresse courriel * restreindre l’accès à une certaine audience de l’API, de sorte qu’un utilisateur ne puisse pas obtenir un jeton d’accès pour une autre audience de l’API ou qu’il ne puisse pas obtenir un jeton d’accès pour cette audience dans certaines circonstances. Dans ce cas, si vous créez une audience API personnalisée pour chaque organisation, votre Règle doit également garantir que l’utilisateur qui s’authentifie appartient à l’organisation qui correspond à l'audience API correspondante. L’accès à Management API Auth0 n’est pas limité par l’organisation. L’accès à Management API Auth0 se fait au moyen d’un jeton d’accès attribué pour une utilisation dans un contexte de communication entre machines et ne peut pas être limité par une Auth0 Organization (Organisation Auth0). Par conséquent, ne donnez pas à vos clients un accès direct à votre instance de Management API Auth0. Si vos clients doivent gérer des aspects de leur organisation, tels que les comptes utilisateurs (voir [Profile Management (Gestion des Profils)](/docs/fr-ca/get-started/architecture-scenarios/multiple-organization-architecture/single-identity-provider-organizations/profile-management)), vous devez créer votre propre application et/ou API indépendante pour cela.