Azure Application vs. Delegated Permissions

What is the difference between Application Permissions and Delegated Permissions?

In Azure (Microsoft Entra ID), the key difference is that Delegated Permissions let an app act on behalf of a signed-in user, while Application Permissions let the app act independently as itself. Delegated permissions are tied to user identity and limited by what that user can access, whereas application permissions are granted to the app’s service principal and require admin consent for tenant-wide access.

🔑 Delegated Permissions (User Context)

• Definition: App acts as the signed-in user.
• Authentication Flow: Requires user sign-in (Authorization Code, Implicit, On-Behalf-Of, Device Code).
• Consent: Can be granted by the user (for their own data) or by an admin (for org-wide delegated scopes).
• Scope: Limited to what the user can access.
• Example in Azure: A Teams add-in that reads files using Files.Read.All — it can only read files the signed-in user has access to, not tenant-wide.

🔑 Application Permissions (App Context)

• Definition: App acts as itself (service principal), not tied to a user.
• Authentication Flow: Uses client credentials flow (client ID + secret/certificate).
• Consent: Must be granted by an administrator because the app can access org-wide data.
• Scope: Tenant-wide or resource-wide access, regardless of individual user rights.
• Example in Azure: A background service that syncs all users’ calendars nightly using Calendars.Read.All.

⚖️ Comparison in Azure Context

Feature	Delegated Permissions User-context access	Application Permissions App-context access
Identity	Requires user sign-in	No user required
Acts as	Signed-in user	Service principal (app)
Authentication	Authorization Code, Implicit, On-Behalf-Of	Client Credentials flow
Consent	User or Admin	Admin only
Scope	User’s accessible data	Org-wide resources
Use Cases	Interactive apps, Teams bots, web front ends	Background daemons, automation scripts, sync services
Risk	Limited to user privileges	Broad access, higher security risk

Sources:

🧩 Practical Guidance

• Use Delegated Permissions when building interactive apps that need to act only while a user is signed in (e.g., Outlook add-ins, Teams bots).
• Use Application Permissions for background services or automation that must run without user interaction (e.g., nightly sync jobs, reporting services).
• Security Best Practice: Always enforce least privilege — request only the minimum permissions needed, review admin consents regularly, and monitor app activity logs in Azure.

👉 In short:

• Delegated = user-centric, interactive scenarios.
• Application = app-centric, background or automation scenarios.

Here’s how you configure Delegated vs Application Permissions in Azure Portal (Microsoft Entra ID) step-by-step:

🧩 Configuring Delegated Permissions

1. Go to Azure Portal → Microsoft Entra ID → App registrations.
2. Select your app → API permissions.
3. Click Add a permission → choose Microsoft Graph (or another API).
4. Select Delegated permissions.
   • Example: User.Read, Mail.Read.
5. Save.
   • If the permission only affects the signed-in user, they can consent themselves.
   • If it requires org-wide delegated access, an admin must grant consent.

Result: Your app will require a user to sign in, and it can only access what that user has rights to.

🧩 Configuring Application Permissions

1. Go to Azure Portal → Microsoft Entra ID → App registrations.
2. Select your app → API permissions.
3. Click Add a permission → choose Microsoft Graph (or another API).
4. Select Application permissions.
   • Example: Calendars.Read.All, User.Read.All.
5. Save → Click Grant admin consent (only admins can do this).
6. Configure Certificates & secrets so the app can authenticate using the client credentials flow.

Result: Your app runs as its own identity (service principal) and can access tenant-wide data without user sign-in.

⚖️ Quick Comparison in Azure Portal

Aspect	Delegated Permissions	Application Permissions
Where to configure	App Registration → API Permissions	Same place
Consent	User or Admin	Admin only
Auth flow	Requires user sign-in (OAuth)	Client credentials (secret/cert)
Scope	Limited to user’s access	Tenant-wide / org-wide
Best for	Interactive apps	Background services

👉 In practice:

• A web app where users log in and see their own data → Delegated.
• A daemon service that syncs all org calendars nightly → Application.