Table of Contents
Introduction
October is Cybersecurity Awareness Month, a reminder that protecting identity and data is everyone’s responsibility, especially in cloud-first environments. As organizations deepen their reliance on Microsoft 365 and Entra ID, understanding how applications gain access to corporate resources has never been more critical.
Access control sits at the heart of Microsoft 365 and Entra ID security. Every permission you grant, whether to a user, application, or service principal defines who can interact with corporate data and how.
For system architects and administrators, understanding the difference between delegated and app-only access isn’t just a technical nuance; it’s essential for preventing data exposure, privilege escalation, and consent-based attacks.
Modern organizations rely heavily on integrations, custom apps, automation scripts, backup agents, or Power Platform connectors – all of which authenticate through Microsoft Entra ID. Knowing how these apps access resources helps you enforce least privilege, evaluate consent requests, and monitor what happens behind the scenes.
Overview
Applications in Microsoft Entra ID can access organizational data in two primary modes:
1. Delegated Access (On Behalf of a User)
Delegated access occurs when an application acts as the signed-in user.
It requires:
- The user to sign in and grant consent.
- The application to request delegated permissions (scopes) such as
Mail.ReadorFiles.Read.All.
The app’s access is limited by:
- The user’s existing rights to the data.
- The scopes consented to by the user or an admin.
If a Global Administrator signs in, the app temporarily inherits their privileges, creating potential risk if either the account or app is compromised.
Example:
A Teams add-in using delegated Files.Read.All can only read files the signed-in user can access, never tenant-wide content.
OAuth 2.0 Flow (Simplified):
- User authenticates interactively via the Microsoft identity platform.
- Entra ID displays a consent screen with the requested scopes.
- Upon approval, Entra ID issues an access token representing both user and app permissions.
- The app uses this token to call APIs such as Microsoft Graph.
2. Application Permissions (Access without a user)
App-only access allows an application to act independently of any user, using its own identity.
The app’s rights come entirely from admin-granted application permissions, like User.Read.All or Mail.Send.
Common in automation, reporting, and backend integrations, this model is powerful but risky: a compromised app credential (client secret or certificate) grants tenant-wide access.
Example:
A compliance automation tool with Files.Read.All app-only permission can access all users’ OneDrive files—even without any user logged in.
OAuth 2.0 Flow (Client Credentials Grant):
- The app authenticates using its credentials (client secret or certificate).
- Entra ID verifies the identity and issues an app-only access token.
- The token represents the service principal, not any specific user.
- API calls are logged as service principal activity.
Comparison Table
| Aspect | Delegated Permissions | Application Permissions |
|---|---|---|
| Identity Context | Acts on behalf of a signed-in user | Acts as its own service principal |
| Authentication | Requires user sign-in and consent (OAuth 2.0 Authorization Code Flow) | Uses client secret, certificate, or managed identity (Client Credentials Flow) |
| Permission Scope | Limited by user rights and requested scopes | Defined by application-level permissions |
| Risk Surface | Inherits user privileges, risky if user has elevated roles | Tenant-wide exposure if app credentials are compromised |
| Visibility in Logs | Appears as user activity | Appears as service principal activity (less transparent) |
| Who Can Consent | Users (for personal data) or admins (for all users) | Admins only |
| Consent Method | Shown interactively at sign-in | Configured statically in app registration |
| Lifespan | Session-based; expires with user tokens | Persistent; remains active until credentials expire or revoked |
| Typical Use Case | User-centric apps (e.g., Outlook add-ins, Teams bots) | Background daemons, automation scripts, or data sync agents |
Security Risks and Attack Scenarios
Both permission types can be secure when scoped properly but both become dangerous when permissions are broader than required.
Delegated Permissions Access Risks
- Users unknowingly approve apps with excessive scopes (
Mail.ReadWrite.All). - Apps inherit Global Admin privileges from highly privileged sign-ins.
- Attack scenario: A malicious actor launches a consent phishing attack, tricking a user into granting “Send mail as you” permission. The attacker now impersonates the user to perform Business Email Compromise (BEC).
Application Permissions Access Risks
- Developers grant wide-ranging admin consent (e.g.,
User.ReadWrite.All) for convenience. - Secrets or certificates stored insecurely in code repositories.
- Attack scenario: A leaked client secret for an app with
Directory.ReadWrite.Allallows silent privilege escalation—creating shadow accounts or modifying security settings, without triggering MFA or user prompts.
At the core, the danger lies not in the permission model itself, but in granting broader access than necessary.
Best Practices for Securing Entra ID App Access
1. Enforce Least Privilege
- Assign only the minimum necessary scopes.
Avoid tenant-wide permissions like*.Allunless absolutely required. - Use incremental consent for delegated apps requesting additional permissions only when needed.
2. Choose the Right Permission Type
- Match the application’s use case to the appropriate access model:
- Delegated: When user context and consent are required.
- App-Only: When no user is involved (e.g., automation or reporting).
- Document and review permission mappings for each integration.
3. Control and Review User Consent
- Configure admin consent workflows in Microsoft Entra ID so that sensitive permissions require approval.
- Disable or limit user consent for external or unverified applications.
- Periodically audit app permissions and consents in the Enterprise Applications → Permissions and Consent blade.
4. Secure App Credentials
- Use certificates or managed identities instead of client secrets whenever possible.
- Restrict client secret creation using Application policies.
- Rotate credentials periodically and avoid embedding them in code or configuration files.
5. Monitor and Audit Regularly
- Review service principals and remove unused app registrations.
- Monitor Sign-In logs and Audit logs for anomalous activity.
- Implement alerting for new high-privilege app consents or app registrations.
6. Educate Users and Developers
- Train users to recognize suspicious consent prompts.
- Instruct developers to request the narrowest scopes possible during app design.
- Embed a security review checkpoint into your app registration workflow.
Conclusion
In my years administering Microsoft Entra ID, I’ve learned one universal truth: application vendors rarely understand the full implications of the permissions their apps request.
I’ve seen requests that could make any security admin’s coffee go cold, like an app demanding Mail.ReadWrite and Mail.Send for every mailbox in the tenant. Yes, every single one. Including the CEO’s.
When I questioned the vendor about it, their response was priceless:
“Sure, we ask for those permissions, but it doesn’t mean we’ll actually use them.”
Of course. Because that’s exactly how least privilege works, right? Ask for the kingdom, but promise you’ll only open the gate occasionally.
It took hours of discussion (and a few deep breaths) to walk them through why that approach was a terrible idea.
This experience reinforced a simple but critical lesson: always verify what permissions an application is requesting and why. Blindly granting broad scopes doesn’t just expand functionality, it expands your attack surface.
Doing due diligence before approving access, verifying scopes, questioning necessity, and understanding the real reach of permissions, isn’t just best practice; it’s the difference between secure automation and unintentional data sprawl.
Thank you for stopping by. ✌️