Microsoft Graph API is the gateway to data and services in Microsoft 365, but access must be carefully managed. This is where “Delegated Permissions” and “Application Permissions” come into play. Both determine how an app interacts with Microsoft Graph, but they serve different purposes and have distinct security implications.
In this blog post, you’ll not only learn the differences but also when to use which type of permission – in a practical and understandable way.
1. Delegated Permissions: The App Acts on Behalf of the User
What does it mean?
With Delegated Permissions, the app operates on behalf of a signed-in user. The app inherits the user’s identity and can only perform actions that the user is permitted to do.
Example from practice:
Imagine you’re building an app that reads Outlook calendar entries. With delegated permissions, the app gets access – but only to the calendar of the signed-in user. Other mailboxes remain off-limits.
Security considerations:
- A user must authenticate (e.g., via OAuth 2.0).
- The app can only operate within the user’s permissions.
- Ideal for scenarios where access should be user-dependent.
When are Delegated Permissions useful?
- Web apps operating on behalf of a user
- Bots or scripts automating user actions
- Mobile apps accessing user data
2. Application Permissions: The App Acts Independently
What does it mean?
With Application Permissions, the app acts independently, without requiring a signed-in user. It has its own identity (App Registration in Azure AD) and can access all relevant data in the tenant.
Example from practice:
You develop a reporting tool that regularly reads OneDrive files, regardless of whether users are logged in. In this case, the app needs Application Permissions to access all files, not just those of a single user.
Security considerations:
- No user authentication required
- The app can access large datasets within the tenant
- Often requires Admin Consent
When are Application Permissions useful?
- Background processes (e.g., data synchronization)
- Automated reports and backups
- Apps that need access to multiple users or the entire organization
3. Delegated vs. Application Permissions: A Direct Comparison
| Feature | Delegated Permissions | Application Permissions |
|---|---|---|
| Access type | On behalf of a user | Independent app access |
| User login required? | Yes | No |
| Access scope | Only what the user can access | Tenant-wide or specific resources |
| Admin consent needed? | Usually not (unless sensitive data) | Almost always required |
| Typical use case | Web or mobile apps | Background processes, automation |
4. How to configure in Azure?
When creating the app registration, you can add the necessary API permissions. After clicking on “Microsoft Graph,” you will be presented with the option to choose between Delegated or Application permissions. You can then define in detail what specific permissions are needed.
To know the exact permission you need, you should check the official Microsoft-Documentations
5. Best Practices: Which Permissions to Choose?
- Use Delegated Permissions if the app operates within a user context.
- Use Application Permissions if the app needs to work independently.
- Apply the “Least Privilege” principle and avoid unnecessary permissions.
- Check if admin consent is required when using Application Permissions.
Conclusion: The Right Permission Choice Ensures Security & Functionality
Microsoft Graph API offers powerful capabilities – but with great power comes great responsibility. Whether to use Delegated or Application Permissions depends on whether the app should act within a user context or work autonomously. Making the right choice enhances security and ensures seamless integration.
Which scenario are you working on? Share your thoughts in the comments – happy to discuss!