Introduction
In today’s cloud-first world, identity and access management (IAM) is a critical part of securing modern applications. Microsoft Entra ID (formerly Azure Active Directory) provides developers and IT administrators with a powerful way to integrate applications using the Microsoft Graph API.
But one of the most confusing areas for beginners and even experienced professionals is understanding Graph API permissions — particularly the difference between Delegated Permissions, Application Permissions, and App Roles.
This guide provides a complete explanation with practical examples so you can confidently configure permissions for your apps and ensure the principle of least privilege in your environment.
What is Microsoft Graph API?
The Microsoft Graph API is the gateway to Microsoft 365 data and services. It allows applications to securely access resources like:
User profiles (emails, phone numbers, manager relationships)
Calendars & events
Teams & chat messages
SharePoint & OneDrive files
Security alerts & identity management features
Instead of using multiple APIs, developers use Microsoft Graph as a single endpoint (https://graph.microsoft.com) to connect apps with Microsoft 365 services.
However, before an app can call Microsoft Graph, it needs permissions — and this is where Delegated vs Application permissions come into play.
Types of Microsoft Graph API Permissions
Microsoft Graph defines two primary permission types:
-
Delegated Permissions
-
Application Permissions
Additionally, App Roles are sometimes used to manage fine-grained access for users and apps.
Let’s explore each in detail.
What are Delegated Permissions?
Delegated Permissions are used when an application is accessing Microsoft Graph on behalf of a signed-in user.
-
Example: A web app that needs to read the user’s calendar after they log in with their Microsoft account.
-
The app acts as the user’s identity, meaning the app can only do what the user is allowed to do.
-
Requires user consent or admin consent, depending on the sensitivity of the permission.
Real-World Example:
-
A mobile app like Outlook requesting Mail.Read delegated permission.
-
The app can read your emails only when you are signed in, and it cannot exceed your own access rights.
Key Characteristics of Delegated Permissions
-
User context required (cannot work without login)
-
Access limited to what the signed-in user can do
-
Requires OAuth 2.0 authorization flow
-
Common in interactive apps (web, mobile, SPA)
What are Application Permissions?
Application Permissions are used when an app needs to run without a signed-in user.
-
Example: A background service that scans all company users’ calendars for free/busy availability.
-
The app has its own identity (service principal) in Entra ID.
-
Requires admin consent since it often provides broad tenant-wide access.
Real-World Example:
-
A HR system that syncs user data from Microsoft Entra ID to its own database every night using User.Read.All.
-
Since no user is logged in, application permissions are needed.
Key Characteristics of Application Permissions
-
No user required (runs as the app itself)
-
Requires client secret or certificate authentication
-
Powerful, tenant-wide access (must be carefully restricted)
-
Common in background jobs, daemons, APIs
What are App Roles in Microsoft Graph?
App Roles are another way to control access for users and applications. They are defined at the app registration level and can be:
-
Assigned to users or groups (to control what features they can access inside the app).
-
Assigned to other applications (to control inter-app access).
Example of App Roles:
-
In a payroll application, you might define roles such as:
-
Payroll.Admin (full access)
-
Payroll.Viewer (read-only access)
-
Users can be assigned to these roles via Enterprise Applications in Entra ID.
While App Roles are not the same as Graph API permissions, they often work together to enforce role-based access control (RBAC).
Major Differences: Delegated vs Application Permissions
When to Use Delegated vs Application Permissions
Use Delegated Permissions When:
-
You need to access user-specific data (emails, calendar, files).
-
Your app is interactive (web app, SPA, mobile).
-
You want permissions scoped to each user’s rights.
Use Application Permissions When:
-
You need to access data across all users.
-
The app runs without user interaction (background tasks).
-
You require system-level automation (e.g., sync jobs, monitoring tools).
Security Best Practices for Graph API Permissions
-
Follow Least Privilege Principle
-
Only request the minimum permissions needed.
-
Example: Use User.ReadBasic.All instead of User.Read.All if you only need basic profile info.
-
-
Admin Consent Workflow
-
Ensure administrators carefully review application permissions before granting tenant-wide access.
-
-
Use Conditional Access Policies
-
Control when and how apps can access Graph API.
-
-
Rotate Client Secrets and Certificates
-
Always secure and rotate credentials for applications.
-
-
Audit & Monitor Permissions
-
Regularly check which apps have permissions granted using:
Get-MgServicePrincipal -All | Select-Object DisplayName, AppId
-
Common Microsoft Graph API Permissions Examples
Delegated Permissions
-
User.Read → Sign-in and read user profile
-
Mail.Read → Read user’s emails
-
Calendars.ReadWrite → Read/write user calendar
Application Permissions
-
User.Read.All → Read all users’ profiles (tenant-wide)
-
Mail.ReadBasic.All → Read basic mail for all users
-
Directory.ReadWrite.All → Read and write directory data
Microsoft Graph API Permission Consent Flow
-
User Sign-In (Delegated)
-
User is redirected to Microsoft login
-
Consents to requested permissions
-
Receives an access token
-
-
Service Authentication (Application)
-
App authenticates with client secret or certificate
-
Admin grants permissions once
-
Receives application token
-
Practical Example: Delegated vs Application Permission
Scenario 1: Delegated Permission
-
App: A meeting scheduler app
-
Required Permission: Calendars.Read (delegated)
-
Behavior: User logs in → App can only read that user’s calendar
Scenario 2: Application Permission
-
App: A company-wide HR tool
-
Required Permission: Calendars.Read.All (application)
-
Behavior: App syncs all users’ calendars every night, no login required
Conclusion
Understanding Microsoft Graph API permissions is critical for developers and IT administrators working with Microsoft 365 and Entra ID.
-
Delegated Permissions → Best for user-context interactive apps
-
Application Permissions → Best for background services & system apps
-
App Roles → Provide fine-grained access control for both users and apps
By applying the principle of least privilege, securing secrets, and regularly auditing permissions, organizations can balance productivity with security.
Leave a Reply