What is Application Consent?

Definition

Application Consent in Microsoft Entra ID is the process by which a user or administrator explicitly authorizes an OAuth application to act with specific permissions against the user's data or the tenant's data.

Consent is what links an App Registration's requested permissions to actual permissions held by the Service Principal in a tenant.

In simple terms:

Consent is the moment "this app wants permission X" becomes "this app has permission X."

---

Why Consent Matters

• Misused consent flows are a top phishing vector in 2024–2026 (consent phishing / illicit consent grants).
• Once granted, consent persists across password resets and bypasses MFA.
• Application permissions consented by admins can grant tenant-wide access to mailboxes, files, and directory.
• Standard users can often consent on their own behalf to common scopes — sometimes powerful ones.

---

Two Permission Models

Delegated Permissions

App acts on behalf of the signed-in user. Effective permission = intersection of (app permissions consented) ∩ (user's actual permissions).

Examples: Mail.Read (read user's mailbox), Files.Read (read user's files).

Application Permissions

App acts as itself, no signed-in user. Has the full scope of the granted permission, regardless of any user.

Examples: Mail.ReadWrite.All (read/write every mailbox in the tenant), Application.ReadWrite.All (manage all apps), Directory.ReadWrite.All (manage directory).

Application permissions always require admin consent.

---

Consent Types

User Consent

User signs in to an app and grants delegated permissions for themselves. Default scopes are typically allowed; sensitive scopes can be restricted by tenant policy.

Admin Consent

Administrator grants permissions for the entire tenant. Required for:

• Application permissions.
• High-privilege delegated permissions.
• Permissions where the tenant has restricted user consent.

Admin Consent Workflow

When users encounter scopes they can't consent to, a request can be routed to admins for approval — visible, auditable, governable.

---

Anatomy of a Consent Prompt

A consent prompt shows:

• App display name.
• Publisher name (verified or not).
• Requested permissions and what each enables.
• "Accept" / "Cancel" buttons.

Verified publisher is a strong signal but not foolproof — attackers have used compromised legitimate apps in the past.

---

Consent Phishing (Illicit Consent Grant)

A real-world attack pattern:

1. Attacker creates a multi-tenant App Registration with malicious permissions (Mail.ReadWrite, Files.Read.All).
2. Sends phishing email with link: "Click to view secure document."
3. Link goes to Microsoft's real consent endpoint with attacker's app ID + scopes.
4. User signs in with real Microsoft 365 credentials, sees consent prompt.
5. User clicks Accept (often without reading).
6. Attacker's app now has persistent access to user's mailbox and files.
7. Password resets and MFA changes don't revoke this access.

This is MITRE ATT&CK T1528 (Steal Application Access Token).

---

Real-World Examples

1. Microsoft Storm-0558 / Midnight Blizzard

OAuth apps and consent abuse have featured prominently in nation-state attacks against Microsoft tenants.

2. Consent Phishing Campaigns

Microsoft's threat intelligence has tracked numerous campaigns using malicious OAuth apps with names like "Document Viewer," "Mail Helper," etc., targeting M365 users worldwide.

3. Stale Admin Consent

A SaaS app was admin-consented in 2018 with Mail.ReadWrite.All. The app is no longer used but the SP still has the permission. Vendor compromise = mass mailbox access.

4. Internal App Permission Drift

Internal app started with User.Read. Over time, devs added Mail.Send, then Files.ReadWrite.All, then Directory.Read.All — all admin-consented. App scope balloons unnoticed.

---

Consent Best Practices

User Consent

1. Restrict user consent to "Allow user consent for apps from verified publishers, for selected permissions" or stricter.
2. Block high-risk scopes for user consent (Mail.ReadWrite, Files.ReadWrite, etc.).
3. Enable admin consent workflow so users can request rather than self-consent.
4. User education on consent prompts.

Admin Consent

5. Centralize admin consent to a small group (Cloud Application Administrator).
6. Document business justification for each tenant-wide consent.
7. Quarterly review of admin-consented apps.
8. Revoke unused consents.

Detection

9. Audit log alerts on Consent to application events.
10. Use Microsoft Defender for Cloud Apps OAuth app discovery and risk scoring.
11. Watch for new app sign-ins with high permissions.

Governance

12. App vetting process before admin consent for new apps.
13. Require verified publisher for any admin-consented app where possible.
14. Tag and own every consented app.

Lifecycle

15. Revoke consent on app decommission.
16. Rotate / remove credentials when consent is revoked.

---

Application Consent Checklist

• User consent restricted for high-risk scopes?
• Admin consent workflow enabled?
• Admin consent role limited to small group?
• All admin-consented apps documented and owned?
• Quarterly review of consented OAuth apps?
• Audit log alerts on consent events?
• Microsoft Defender for Cloud Apps OAuth discovery enabled?
• User awareness training on consent phishing?
• Decommission process revokes consent?

---

How Forestall Helps

Forestall maps the consent landscape:

• Lists all OAuth-consented apps (user and admin) with scopes.
• Highlights high-risk Application permissions.
• Identifies stale consents and orphaned apps.
• Surfaces consent-phishing-style anomalies (newly consented apps with sensitive scopes from unverified publishers).
• Tracks the data attackers could reach via existing consents.

---

Frequently Asked Questions

Can I disable all user consent?

Yes — set "Do not allow user consent." All apps then route through admin consent workflow.

Does revoking consent kick out existing tokens?

It prevents new tokens. Existing access tokens may remain valid for ~1 hour; refresh tokens are invalidated.

Are Microsoft first-party apps safe by default?

Generally yes, but they still represent privilege you should understand. Some still require admin consent for sensitive scopes.

How do I detect consent phishing?

Watch sign-in logs for new apps with sensitive scopes used for the first time across multiple users in a short window.

Can MFA prevent consent phishing?

It prevents the credential theft path but not the consent itself — the user still signs in legitimately and grants consent. Consent phishing bypasses MFA in that sense.

---

Conclusion

Application consent is how OAuth permissions become real in your tenant — and how attackers gain persistent, MFA-resistant access when consent is mismanaged. Restrict user consent to safe scopes, route everything else through an admin consent workflow, govern admin consent decisions deliberately, audit existing consents continuously, and react to anomalies fast. With these controls in place, OAuth becomes a productivity enabler instead of a quiet backdoor into your cloud.