15.1 How OAuth Consent Works in M365
How OAuth Consent Works in M365
OAuth consent is the mechanism that allows third-party applications to access M365 data on behalf of a user. When you click “Sign in with Microsoft” on a website, or when a business application requests access to your calendar, you are granting an OAuth consent. The consent prompt lists the permissions the application requests — and the user clicks “Accept.”
The problem: users click Accept without reading.
Delegated vs application permissions
Delegated permissions act on behalf of a signed-in user. The application can only access data the user can access. If the user can read their own mailbox, the application with delegated Mail.Read can read that user’s mailbox. If the user cannot access another user’s mailbox, neither can the application.
Application permissions act as the application itself — no signed-in user required. An application with application-level Mail.ReadWrite.All can read and modify every mailbox in the tenant. Application permissions require admin consent (an administrator must approve them). Delegated permissions can be consented by the user themselves — this is the attack vector.
The consent phishing attack
The attacker registers a malicious application in their own Azure AD tenant. The application requests delegated permissions: Mail.ReadWrite (read and modify the user’s email), Contacts.Read (read the user’s contacts), Files.ReadWrite.All (read and modify all files the user can access), and User.Read (read the user’s profile).
The attacker sends the user a phishing email or message containing a link that triggers the OAuth consent prompt. The prompt shows the application name (which the attacker chose — it might be “Microsoft Document Viewer” or “IT Security Update Tool”) and the permissions it requests.
The user sees a Microsoft-branded consent prompt asking them to approve an application. It looks official. They click Accept.
The application now has a persistent OAuth grant to access the user’s mailbox, contacts, and files. The application authenticates using its own client credentials plus the user’s delegated consent — no user password needed, no session token needed, no MFA needed. The grant persists until explicitly revoked.
Why this is worse than credential theft
Survives password reset. The application does not use the user’s password. Changing the password has no effect.
Survives token revocation. The application has its own tokens issued based on the consent grant — revoking the user’s tokens does not affect the application’s tokens.
Survives MFA re-registration. MFA protects user authentication. The application authenticates with client credentials — MFA is irrelevant.
No sign-in log entry for the user. The application’s API calls appear in the application’s sign-in logs (AADServicePrincipalSignInLogs), not in the user’s sign-in logs (SigninLogs). An analyst checking the user’s sign-in logs sees nothing suspicious.
Persists indefinitely. OAuth consents do not expire. The grant is valid until an administrator revokes it — which could be never if nobody checks.
The permissions that matter
Not all permissions are equally dangerous. A consent to User.Read (read basic profile) is low-risk. A consent to Mail.ReadWrite.All is a full mailbox compromise. The investigation must assess the permissions granted.
| Permission | Risk | What it allows |
|---|---|---|
| User.Read | Low | Read the user’s name, email, photo |
| Mail.Read | High | Read all email in the user’s mailbox |
| Mail.ReadWrite | Critical | Read, create, modify, delete email |
| Mail.Send | Critical | Send email as the user |
| Files.ReadWrite.All | Critical | Read and modify all accessible files |
| Contacts.Read | Medium | Read all contacts |
| Directory.ReadWrite.All | Critical | Read and modify directory objects |
| MailboxSettings.ReadWrite | High | Modify mailbox settings (create rules) |
The investigation question: What permissions did the malicious application receive? The answer determines the data exposure scope and the urgency of revocation.
Subsection artifact: The permission risk table. Reference this during any OAuth consent review to quickly assess the risk of a consent grant.
Knowledge check
The consent prompt — what users see
Understanding what the user sees explains why they click “Accept.”
The Microsoft consent prompt displays: the application name (chosen by the attacker — “Microsoft Security Update Tool” looks official), the publisher name (if verified — attackers use unverified applications, so no publisher badge appears), and the permissions requested (in user-friendly language — “Read your mail” rather than “Mail.ReadWrite”).
The consent prompt is hosted on login.microsoftonline.com — a legitimate Microsoft domain. The browser shows the Microsoft logo, the HTTPS padlock, and the microsoft.com domain. Everything looks authentic because it IS authentic — it is the real Microsoft consent prompt. The malicious element is the application requesting consent, not the consent interface itself.
Why users click Accept: They see a Microsoft-branded prompt. The application name sounds legitimate. They received an email (the phishing email) telling them to complete this step. The permission descriptions sound harmless (“Read your mail” — “my mail app reads my mail, that makes sense”). And critically: they have clicked “Accept” on consent prompts before for legitimate applications (Zoom, Slack, Adobe) — the action is familiar and does not trigger suspicion.
This is why user training alone cannot prevent consent phishing. The consent prompt is indistinguishable from a legitimate prompt. The only reliable prevention is to remove the user’s ability to consent (admin consent workflow — subsection 15.7).
Check your understanding
1. A malicious OAuth application has delegated Mail.ReadWrite permission for a user. You reset the user's password and revoke all their tokens. Can the application still read the user's email?
2. Where do the malicious application's API calls appear in the logs?