Question

Difficulty: HardApp Registrations and Service Principals

You are developing a multi-tenant daemon application that will run on-premises and read calendar data from multiple customer organizations using Microsoft Graph. The application does not have a user interface and must run without user interaction.

You need to register the application, establish consent in a customer's tenant, and acquire an access token to access their data.

In which order should you perform the steps? To answer, move all actions from the list of actions to the answer area and arrange them in the correct order.

  1. 1In your home tenant, register the application, configure it as multi-tenant, define the required Microsoft Graph Application permissions, and generate a client secret.
  2. 2Construct the administrator consent URL containing the client ID of the registered application and a valid redirect URI.
  3. 3Direct the customer's Global Administrator to navigate to the consent URL and sign in to approve the requested permissions.
  4. 4Verify that the service principal (Enterprise Application) representing your application is created in the customer's tenant.
  5. 5Submit a POST request with the client credentials to the customer's specific token endpoint to obtain the access token.

Answer

First, register the multi-tenant application and configure its application permissions and client secret in the home tenant. Second, construct the administrator consent URL using the application's client ID. Third, have the customer's administrator access the URL to grant consent. Fourth, verify the service principal is created in the customer's tenant. Lastly, request an access token from the customer's token endpoint using the client credentials.
The correct order proceeds from registering the application in the provider's home tenant to generate the client ID, constructing the admin consent URL, obtaining tenant-wide consent from the customer's administrator, verifying the local service principal's creation, and finally requesting the access token from the customer's specific endpoint.

Step-by-Step Solution

1
Register the application in the home tenant and configure its metadata, supported account types (multi-tenant), and credentials.
The application registration is created, yielding a client ID and a client secret.
You must establish the identity definition and authentication credentials before any tenant-level operations or token requests can occur.
2
Construct the admin consent request URL targeting the Microsoft Entra ID endpoint, appending the client ID and redirect URI.
A valid consent URL is prepared for the customer's tenant administrator.
Since daemon apps use client credentials flow (Application permissions), there is no interactive sign-in flow to trigger dynamic consent; therefore, the administrator consent endpoint must be explicitly called.
3
Have the customer's Global Administrator navigate to the consent URL and sign in to approve the permissions.
Consent is granted to the application for the customer's tenant.
Only a tenant administrator can grant consent for Application-level permissions (such as reading calendar data across all mailboxes).
4
Confirm the instantiation of the service principal in the customer's tenant.
A service principal (Enterprise Application object) is created in the customer's tenant.
The service principal acts as the local identity representation of the application in the target tenant and holds the delegated or consented permissions.
5
Perform a client credentials token request using the client secret to the customer's specific token endpoint.
An OAuth 2.0 access token is returned by Microsoft Entra ID for the target customer tenant.
With consent established and the service principal present, the daemon can securely request a token specifically scoped to the customer's resources.

Key Concept

Multi-tenant application registration, administrative consent flow, and service principal instantiation for daemon applications using Microsoft Entra ID.
Estimated Time:2m 30s
Rate this question