> ## Documentation Index > Fetch the complete documentation index at: https://auth0.com/llms.txt > Use this file to discover all available pages before exploring further. > Learn about authorizing users for Organizations in multi-tenant architectures. # Single Identity Provider: Authorization When thinking about authorization, you typically need to consider how you determine what a person is allowed to do and how you communicate this information to your applications and/or APIs. Depending on the applications you have, you may be affected by one or both of these. In our architecture scenarios, we provide general purpose guidance on [B2B Authorization](/docs/get-started/architecture-scenarios/business-to-business/authorization), which we recommend reviewing alongside the guidance provided here. * [ID Tokens](/docs/secure/tokens/id-tokens) are often used to convey user authorization information to applications through custom claims, which can be added using [Rules](/docs/customize/rules) extensibility. Added claims can allow you to present a user interface in which users don’t have the ability to attempt something they are not permitted to do. Authorization information in an ID Token also provides any application backend with a way to restrict users from bypassing frontend controls for traditional web apps. **Best Practice** You can leverage [Auth0 Role-Based Access Control](/docs/manage-users/access-control/rbac) (RBAC) via the [Auth0 Authorization Core](/docs/manage-users/access-control/configure-core-rbac) feature to define access permissions, which can be automatically applied to Access Tokens. For further details, see [Enable Role-Based Access Control for APIs](/docs/get-started/apis/enable-role-based-access-control-for-apis). Auth0 RBAC functionality can also provide information that you can add as custom claims to identity tokens (and access tokens, if you prefer manual application). Auth0 Organizations can leverage Auth0 RBAC capability via one or more membership-assigned roles. To learn more, see [Add Roles to Organization Members](/docs/manage-users/organizations/configure-organizations/add-member-roles). * APIs that provide public-facing access to shared resource services are typically protected via access control mechanisms. For this purpose, Auth0 provides the ability to create an authorization bearer token, or OAuth 2 [access token](/docs/secure/tokens/access-tokens), which can convey user authorization information to an API, typically by using Auth0 [Role-Based Access Control (RBAC)](/docs/manage-users/access-control/configure-core-rbac) to apply one or more [membership-assigned roles](/docs/manage-users/organizations/configure-organizations/add-member-roles) or by adding custom claims via [Rules](/docs/customize/rules) extensibility. You can also leverage Auth0 RBAC capability to automatically adjust the `scope` claim of an access token. APIs can then use this information to apply the appropriate level of access control, which allows your API to enforce policy rules without having to do an extra lookup to get information about the user. * In certain cases, you may want to implement application-level policies at the Auth0 Tenant; this allows you to apply policies to a whole range of applications and resource services (APIs) without needing to modify each one independently. You typically implement this via [Rules](/docs/customize/rules) extensibility. **Best Practice** Auth0 Organizations provides Auth0 Rules with access to organization-centric information that can be accessed when authenticating a user. This information is available via the `organization` object contained within the Rules `context` object. The `organization` object also provides access to any metadata provisioned against an Organization definition in Auth0. To learn more, see [Custom Development for Organizations](/docs/manage-users/organizations/custom-development). ## ID token claims Usually claims can be added to identity tokens as discussed in our [ID Token Claims](/docs/get-started/architecture-scenarios/business-to-consumer/authorization) best practice guidance. When using the Auth0 Organizations feature, an `org_id` claim is automatically added to any identity token (for an example, see [Work with Tokens and Organizations](/docs/manage-users/organizations/using-tokens)) issued for users with organization membership. This parameter is validated by Auth0 SDKs. You can also add supplemental information associated with an Auth0 Organization by adding a custom claim to the identity token: ```js wrap lines theme={null} context.idToken['http://travel0.net/multifactor'] = context.multifactor; ``` **Note**: If you have configured your tenant to support organization names in the Authentication API, the `org_name` claim is automatically included in ID tokens. To learn more, review [Use Organization Names in Authentication API](/docs/manage-users/organizations/configure-organizations/use-org-name-authentication-api). ### SAML assertion A SAML assertion generated by an upstream Identity Provider (IdP) can be configured to populate standard or custom claims in an identity token consumed downstream. For example, you can define the mappings section of a SAML Enterprise connection: ```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" } ``` In this example, each field is assigned a value in the `user` object in an Action, which maps to standard claims in an ID Token or can be mapped using [custom claims](/docs/secure/tokens/json-web-tokens/json-web-token-claims#custom-claims). To learn more about customizing SAML mappings, read [Connect Your App to SAML Identity Providers: Set up mappings](/docs/authenticate/identity-providers/enterprise-identity-providers/saml#set-up-mappings). When your application uses SAML and Auth0 acts as the IdP, you can include an [Organization](/docs/manage-users/organizations) in the SAML sign-in request using the organization query parameter: ```js wrap lines theme={null} https://{YOUR_AUTH0_DOMAIN}/samlp/{YOUR_APP_CLIENT_ID}?organization={YOUR_ORGANIZATION_ID} ``` Auth0 returns the organization in the SAML response as a custom attribute: ```js wrap lines theme={null} http://schemas.auth0.com/org_id ``` Any non-standard claims included in an OIDC token such as, custom claims set in an Action, are also included in the SAML response, prefixed with `http://schemas.auth0.com/`. ## Access token claims In addition to any other claims you are adding to your access token for access control decisions (see our general [Access Token Claims](/docs/get-started/architecture-scenarios/business-to-consumer/authorization) best practice guidance), you will typically want to communicate the organization to which the user belongs. As with the identity token, when using the Auth0 Organizations feature, the `org_id` claim is automatically added to any access token (for an example, see [Work with Tokens and Organizations](/docs/manage-users/organizations/using-tokens)) issued for users with organization membership. You can also add supplemental information associated with an Auth0 Organization by adding a custom claim to the access token: ```js wrap lines theme={null} context.accessToken['http://travel0.net/multifactor'] = context.multifactor; ``` **Note**: If you have configured your tenant to support organization names in the Authentication API, the `org_name` claim is automatically included in access tokens. To learn more, review [Use Organization Names in Authentication API](/docs/manage-users/organizations/configure-organizations/use-org-name-authentication-api). Alternatively, you could create a unique API audience for each organization, which would result in a unique API definition in Auth0. While this mechanism can mitigate the need for employing custom Rule extensibility, the complexity it introduces can be challenging. A simple comparison is as follows: | Approach | Pros | Cons | | ------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Unique API Audience | | | | Custom Claim | Simplifies Auth0 Tenant configuration. | Custom code needed in a rule to add the organization to the access token. | ### Roles The Auth0 Organizations feature also supports [Role-Based Access Control (RBAC)](/docs/manage-users/access-control/rbac) via the [Authorization Core](/docs/manage-users/access-control/configure-core-rbac) feature associated with an Auth0 Tenant. RBAC is [applied at the Auth0 Organization membership level](/docs/manage-users/organizations/configure-organizations/add-member-roles). You can [enable Auth0 Authorization Core RBAC for an API](/docs/get-started/apis/enable-role-based-access-control-for-apis), which will result in the default `scope` claim in access tokens being modified automatically and a `permission` claim being added by default (for an example, see [Work with Tokens and Organizations](/docs/manage-users/organizations/using-tokens)). You can also add role information to identity tokens as custom claims by accessing the `authorization` object available in the Rules `context` object. To learn more, see [Rules with Authorization Sample Use Cases: Add User Roles to Tokens](/docs/manage-users/access-control/sample-use-cases-rules-with-authorization). ## Access control Resource-level policy enforcement is the responsibility of the applications and/or APIs in your system. If you attempt to enforce policies in a centralized Authorization Server, such as your Auth0 Tenant, you will quickly run into a complex control system that is difficult to maintain and understand. Instead, your centralized Authorization Server can ensure that the appropriate information about a user is included in the tokens, so that your applications and APIs have the necessary information to make policy enforcement decisions. At the very least, in situations where there is too much information to contain in a single token (for example, resource-level permissions) or where information changes frequently enough that it would be out of date if accessed directly in the token, your applications and APIs should be able to look up the correct information. Some high-level policy enforcement, on the other hand, can be handled in a centralized fashion. For example, when using an Auth0 Tenant context, there are some situations in which you could implement a Rule that mitigates the need for every application and/or API to apply the same restrictions. These include: * blocking access to users from a particular IP address * implementing specific requirements around Contextual or Adaptive MFA * restricting login to only users who have verified their email address * restricting access to a certain API audience, so a user cannot obtain an access token for any other API audience or cannot obtain an access token for that audience under certain circumstances. In this case, if you’re creating a custom API Audience for each organization, your Rule must also ensure that the authenticating user belongs to the organization that matches the corresponding API audience. Auth0 Management API access is not restricted by organization; access to the Auth0 Management API is made via an access token allocated for use within a machine-to-machine context and cannot be constrained by an Auth0 Organization. Therefore, do not provide your customers with direct access to your instance of the Auth0 Management API. If your customers must manage aspects of their organization, such as user accounts (see [Profile Management](/docs/get-started/architecture-scenarios/multiple-organization-architecture/single-identity-provider-organizations/profile-management)), then you should build your own independent application and/or API for this purpose.