Application Allowing Multi-Tenant Authentication

Applications registered in Microsoft Entra ID to facilitate sign-in can apply for either single-tenant or multi-tenant authentication, also known as "sign-in audience." Single-tenant authentication restricts access to users within the same tenant, while multi-tenant authentication allows access to users from any Entra tenant. This distinction between single-tenant and multi-tenant apps can have security implications. Failing to configure an application as multi-tenant with full awareness of its implications and without implementing necessary precautions can pose security risks.

The exposure of multi-tenant apps is higher due to the potential for a malicious Entra user from any tenant to discover and access the application. If the application's code fails to consider this configuration, such as not checking the source tenant of the user against a list of authorized ones, it can result in unauthorized access. Vulnerable apps are those that assume authentication is legitimate and grant access solely based on the presentation of a valid token, without conducting further checks. This type of vulnerability falls within the realm of "authentication (AuthN) vs. authorization (AuthZ)" flaws. According to the "shared responsibility model", Entra ID handles the user authentication, while the authorization aspect falls under the app's responsibility.

Even Microsoft fell victim to this confusion in March 2023, as detailed in the "BingBang" case study. Security researchers were able to exploit this misconfiguration to compromise several Microsoft applications, including the management portal for the Bing search engine. Microsoft addressed this vulnerability in their application, but it serves as a reminder that similar vulnerabilities could affect your own applications and you should review and rectify them as necessary.

Multi-tenant apps are also prone to other authentication confusions, like the nOAuth flaw.

Legitimate use cases for multi-tenant apps exist, especially if your organization hosts applications intended for access by other organizations (e.g., as a software vendor or for inter-organization collaboration) or by users from a different tenant but within the same organization (e.g., with one tenant per subsidiary). These applications are only vulnerable if they rely solely on successful authentication without conducting additional authorization checks. This Indicator of Exposure cannot determine if an application is intended to be public or if multi-tenant authentication was deliberately enabled. It also cannot ascertain whether multi-tenancy is genuinely necessary, and without access to the application code, it cannot verify if the required authorization checks are in place. For these reasons, it flags all multi-tenant applications as findings that you must review individually. Once confirmed, you can mark them as ignored.

Review the application with the assistance of its owner to verify that the multi-tenant nature of the app aligns with expectations. Ensure that this configuration was enabled with full awareness of the differences between single-tenant and multi-tenant apps. Confirm that the application can accommodate users from other tenants besides the one where it is registered.

Certainly, if the application is meant to be public, you can also specify it so this Indicator of Exposure can ignore it.

If the application doesn't require multi-tenant authentication, you can switch it back to single-tenant mode. However, note that Entra ID enforces different validation rules on apps based on supported account types. Therefore, it may not always be possible to switch to single-tenant mode without adjusting other parameters. Proceed with caution and review carefully the implications of any changes.
You can follow Microsoft instructions to update the audience or use the following procedure:

1. Authenticate to Azure portal / Entra admin center with an Entra user who owns the application or who has an Entra role such as Application Administrator or Cloud Application Administrator (the exact required Entra permission is microsoft.directory/applications/audience/update).
2. Open the "App registrations" menu.
3. Search for the application (use its name or object ID shown in the finding).
4. On the "Overview" page, the "Supported account types" section should currently display "Multiple organizations" or "All Microsoft account users".
5. Click the "Authentication" menu and follow the instructions to switch the application to "single-tenant".

On the contrary, if the application requires multi-tenant authentication, verify with its developer that the code includes additional authorization checks on the received authentication tokens, known as claims validation.

• Where applicable, the application should only accept tokens from users originating from a predefined list of identified Entra tenants, such as the tenants of the organization's subsidiaries, based on the tenant ID claim.
• If applicable, the application could also consider accepting tokens from specific users known in advance, based on their object ID claim.
• The application can implement the Role-Based Access Control (RBAC) model using various methods, including Entra App Roles, Entra Groups, or its own data store.

When you confirm that these checks are in place, or if the application is intended to be public, you can mark the application for this Indicator of Exposure to ignore.

Note: Conditional Access policies only apply to users in the same tenant. As a result, they cannot restrict access to your multi-tenant applications by users from other tenants.

Moreover, we recommend following Microsoft's official guidance on potential misconfiguration of authorization for multi-tenant applications using Entra ID, which includes additional specific recommendations.

Lastly, raise awareness among Entra and Azure administrators to ensure they choose wisely between single-tenant and multi-tenant configurations when creating applications either through the Entra app registration page or via the creation of an Azure App Service.

Name: Application Allowing Multi-Tenant Authentication

Codename: APPLICATION-ALLOWING-MULTI-TENANT-AUTHENTICATION

Severity: Low