Share via

Microsoft Entra ID multi-tenant client credentials flow

Steven Devooght 20 Reputation points
2023-12-15T11:45:02.4433333+00:00

We have developed a multi-tenant HTTP API hosted in Azure, utilized by various daemon clients both on-premise and in the Azure Cloud. These daemon clients are our creations so the API is the foundation upon which our other products depend. In terms of authentication, we implement the OAuth2 client credentials flow. Currently, the API serves as a host for authorization (IdentityServer4). Consequently, the resource server and authorization server are co-deployed. This setup enables the creation of multiple OAuth2 clients per tenant. The acr_values play a crucial role on the token endpoint, facilitating the transmission of tenant information.

curl -X 'POST' \
  'https://localhost:44317/connect/token' \
  -H 'accept: */*' \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -d 'client_id=1337c7c2-3f42-41bb-9ba9-2c85cacfaa4b&client_secret=test&grant_type=client_credentials&acr_values=tenant%3Atenant-a'

Currently, we are exploring the use of Microsoft Entra ID as our authorization server. Protecting the API itself appears straightforward through a multi-tenant app registration. As for client app registrations, we are considering a few options:

1. Multi-Tenant App Registration in Home Tenant per Daemon Client

Using a multi-tenant app registration in our home tenant for each daemon client poses challenges. It would entail using the same secret among all customers, which is not ideal, especially for on-premise daemons where secure secret storage is hard. Additionally, we aim to maintain authentication isolation between our tenants.

2. Single-Tenant App Registration in Customer's Entra ID per Daemon Client

Using a single-tenant app registration in the customer's Entra ID for each daemon client offers the advantage of providing each customer with its own secret. However, a notable drawback is that the responsibility of configuring and rotating the secret falls on the customer. This arrangement feels awkward, particularly as we are both the developers of the client and API. Having authentication mediated through our customer, especially in machine-to-machine flows, adds an additional layer that seems weird.

3. Single-Tenant App Registration in Home Tenant per Daemon Client, per Tenant

Creating a single-tenant app registration in our home tenant for each daemon client, per tenant, could address the issue of shared secrets. However, identifying the tenant becomes challenging, as all clients would originate from the same issuer.

4. Internal Setup of Entra ID Tenant per Customer

Establishing an Entra ID tenant internally for each customer and configuring the clients within offers the advantage of each customer having its own secret. Tenants can be distinguished since tokens will be issued by different Entra ID instances. However, this option raises concerns about maintenance, given the substantial number of customers (100) and client apps (5+) resulting in the management of 500 app registrations, including secret rotations, presenting a potential maintenance nightmare.

In our current solution with IdentityServer4, we've developed a user interface for configuring clients per tenant. The solutions involving Microsoft Entra ID appear considerably more complex than what we currently have, unless there's something we might be overlooking?

Microsoft Security | Microsoft Entra | Microsoft Entra ID

1 answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Shweta Mathur 30,456 Reputation points Microsoft Employee Moderator
    2023-12-18T13:16:08.1166667+00:00

    Hi @Steven Devooght ,

    Thanks for reaching out.

    It depends on your specific scenario and requirements.

    Single-Tenant vs Multi-Tenant App Registration

    If you have a small number of customers and want to manage them separately, you can create a single tenant for each customer. This approach provides more isolation and control over each customer's data and resources. However, it can also increase the administrative overhead of managing multiple tenants.

    On the other hand, if you have a large number of customers and want to simplify management, you can create a multi-tenant application that shares a secret among all customers. This approach allows you to manage all customers in a single tenant and reduces the administrative overhead. However, it also increases the risk of data leakage and requires more careful management of the shared secret.

    Internal Setup of Entra ID Tenant per Customer

    You can establish an Entra ID tenant internally for each customer and configure the clients within. This approach offers the advantage of each customer having its own secret, which can provide more isolation and control over each customer's data and resources.

    However, as you mentioned, this approach can result in a large number of app registrations to manage, which can be a maintenance nightmare. To address this, you can consider using automation tools and processes to manage the app registrations and secret rotations.

    For example, you can use Azure AD PowerShell or Azure CLI to automate the creation and management of app registrations and secrets. You can also use Azure Key Vault to securely store and manage the secrets and use Azure Functions or Azure Logic Apps to automate the secret rotation process.

    Overall, while establishing an Entra ID tenant internally for each customer can provide more isolation and control, it requires careful planning and management to ensure that it is scalable and maintainable for your organization.

    In any case, you should carefully consider the security and compliance requirements of your customers and choose an approach that meets those requirements while also being manageable and scalable for your organization.

    Hope this will help.

    Thanks,

    Shweta

    Please remember to "Accept Answer" if answer helped you.

    Was this answer helpful?

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.