Examkin

Question

Difficulty: HardApp Registrations and Service Principals

A developer is configuring a background service running on an on-premises server that must retrieve data from a custom Web API secured by Microsoft Entra ID. The background service runs autonomously without any user interaction and authenticates using its client secret.

The developer manually updates the Microsoft Entra ID application manifest of the background service to request access to the Web API. In the requiredResourceAccess section of the manifest, the developer adds the correct resource app ID and includes the permission ID in the resourceAccess array, setting the type property of the permission to Scope.

After the developer grants administrator consent, the background service successfully obtains an access token using the OAuth 2.0 client credentials grant flow. However, when the service presents the token to the Web API, the API rejects the request with an HTTP 403 Forbidden error.

What is the cause of this authentication issue?

  1. The permission was configured with a type of Scope instead of Role, which prevents the permission from being included in the token during a client credentials grant flow.Answer
  2. B
    The developer enabled a system-assigned managed identity for the on-premises server, which does not support the client credentials grant flow using a client secret.
  3. C
    The developer did not configure a Key Vault access policy to grant the service principal GET permissions, preventing it from validating the client secret.
  4. D
    The developer configured a Shared Access Signature (SAS) token with restricted scopes instead of registering a service principal to authenticate against Microsoft Entra ID.

Answer

The permission was configured with a type of Scope instead of Role, which prevents the permission from being included in the token during a client credentials grant flow.
The correct answer is correct because background daemon services do not have a signed-in user and must use application permissions, which are configured as type 'Role' in the application manifest. Setting the type to 'Scope' configures it as a delegated permission. When the client credentials flow is executed, only 'Role' permissions are included in the generated access token. Therefore, the token returned will lack the expected scopes/roles, resulting in an HTTP 403 Forbidden error when calling the API.

Step-by-Step Solution

1
Analyze the application type and the authentication flow used in the scenario.
The application is a background daemon service running autonomously (no user logged in) and uses the OAuth 2.0 client credentials grant flow.
Daemon services rely on application permissions because there is no signed-in user to consent to delegated scopes.
2
Examine the configuration of the application manifest.
The permission in the manifest is configured with the type property set to Scope.
In Microsoft Entra ID, Scope indicates delegated permissions, while Role indicates application permissions.
3
Determine the impact of the manifest configuration on the client credentials flow token request.
Microsoft Entra ID will not include the permission in the access token because the client credentials grant flow only requests and issues application permissions (Roles).
Since the scope permission is not included in the token, the backend API rejects the token with an HTTP 403 Forbidden error.

Key Concept

Application permissions (Roles) vs. Delegated permissions (Scopes) in Microsoft Entra ID app registrations for daemon applications.
Estimated Time:2m 0s
Rate this question

Topics

App Registrations and Service Principals

More questions from this topic