Question

Difficulty: HardPermissions, Scopes, and Consent

You are developing a secure Web App named InventoryManager that runs on Azure App Service. The application must perform two main tasks:
1. Allow signed-in users to view their own profile details and manage their calendar events in Microsoft 365.
2. Run a scheduled background job every night to retrieve a list of all office groups in the tenant to update local access lists. This background job runs without a signed-in user.

You need to configure the app registration in Microsoft Entra ID.

Which of the following configurations must you apply to meet these requirements while adhering to the principle of least privilege? (Select TWO)

  1. Configure the Microsoft Graph delegated permissions User.Read and Calendars.ReadWrite, and allow signed-in users to consent to these permissions.Answer
  2. Configure the Microsoft Graph application permission Group.Read.All, and have a tenant administrator grant tenant-wide consent.Answer
  3. C
    Configure the Microsoft Graph delegated permission Group.Read.All, and authenticate the background job using the OAuth 2.0 client credentials flow.
  4. D
    Configure the background job to request the specific scope https://graph.microsoft.com/Group.Read.All dynamically during the token request.

Answer

Configure the Microsoft Graph delegated permissions User.Read and Calendars.ReadWrite for user-interactive operations, and configure the application permission Group.Read.All with tenant-wide administrator consent for the background daemon job.
For the user-centric features, the application runs on behalf of the signed-in user. This necessitates delegated permissions (User.Read and Calendars.ReadWrite) which are eligible for user consent. In contrast, the nightly background task operates independently of any user context, which requires a daemon flow (client credentials flow) and application-level permissions. Specifically, Group.Read.All is the correct application permission to read tenant groups, and because it is an application-level permission, it requires tenant-wide administrator consent.

Step-by-Step Solution

1
Analyze the client contexts for the two tasks.
Task 1 involves a signed-in user (delegated context), whereas Task 2 is a background daemon running without a user (application context).
This determines whether delegated or application permissions are required for each task.
2
Select the appropriate permissions under the principle of least privilege.
For the user context, delegated permissions User.Read and Calendates.ReadWrite are needed. For the background context, application permission Group.Read.All is needed.
Least privilege mandates using specific, narrow scopes rather than broad directory-wide administrative scopes like Directory.Read.All.
3
Determine the consent requirements for the selected permissions.
Delegated permissions can be consented to by individual users. Application permissions always require administrator consent.
Application permissions bypass user consent checks and expose tenant-wide data, requiring a tenant administrator to explicitly authorize them.
4
Determine the token request structure for the daemon service.
The client credentials flow must request the scope ending in /.default.
Unlike delegated flows that can request specific scopes dynamically, daemon flows require static permission registration and the use of the default scope suffix.

Key Concept

Differentiating delegated permissions and user consent from application permissions and admin consent in Microsoft Entra ID app registrations.
Rate this question