# What is OAuth consent phishing, and how do you stop it in Microsoft 365?

URL: https://iblockspam.com/blog/oauth-consent-phishing-microsoft-365
Last updated: 2026-10-10
Published: 2026-10-10
Topic: Phishing & threats
Author: iBlockSpam Team

> How illicit consent grants give attackers mailbox access without a password, how to restrict user consent in Entra ID, and how to review and revoke app grants.

## Short answer

OAuth consent phishing tricks a user into approving a malicious app on Microsoft's real consent screen. The app then reads mail or files through its own tokens, so password resets and MFA don't remove it. Stop it by restricting user consent in Entra ID, turning on the admin consent workflow, and regularly reviewing and revoking app permissions.

Most phishing tries to steal a password. Consent phishing doesn't need one. It asks the user to click **Accept** on a genuine Microsoft permission screen, and the attacker's app gets lasting access to their mailbox. This guide explains how the attack works and the Entra ID settings that stop it, using Microsoft's current menu names.

## What is OAuth consent phishing?

Microsoft defines it simply: "Consent phishing attacks trick users into granting permissions to malicious cloud applications" ([Microsoft Learn](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/protect-against-consent-phishing)). The result is called an **illicit consent grant**.

It works because nothing on the screen is fake. "Because a legitimate provider (such as the Microsoft identity platform) hosts the application, unsuspecting users accept the terms." The sign-in page, the domain and the consent prompt are all Microsoft's. Only the app behind them is malicious.

| | Credential phishing | Consent phishing |
|---|---|---|
| What the user gives away | Password and often an MFA session | Permission for an app |
| Where it happens | A fake sign-in page | Microsoft's real consent screen |
| What the attacker holds | A login or a session cookie | The app's own tokens |
| Fixed by a password reset | Partly | No |
| Stopped by phishing-resistant MFA | Yes | No |

That last row matters. Even if you've rolled out [phishing-resistant MFA to stop AiTM attacks](https://iblockspam.com/blog/adversary-in-the-middle-phishing-mfa-bypass), a user who completes MFA and then approves a malicious app has still handed over access.

## How does an illicit consent grant attack work?

Microsoft's [illicit consent grant guidance](https://learn.microsoft.com/en-us/defender-office-365/detect-and-remediate-illicit-consent-grants) describes the pattern:

1. **The attacker registers an app** in Microsoft Entra ID that "requests access to data such as contact information, email, or documents." It's often given a name that sounds like a document viewer, a PDF tool or a security scanner.
2. **A phishing email** asks the user to open a shared file or "verify" something. The link goes to Microsoft's real sign-in and consent flow for that app.
3. **The user approves** the requested permissions.
4. **The app reads data** through Microsoft Graph or other APIs. It "has account-level access to data without the need for an organizational account."
5. **Normal remediation fails.** Resetting the password or requiring MFA "aren't effective against this type of attack, because these apps are external to the organization."

From there, the attacker can search mail for invoices, read conversations to set up [thread hijacking](https://iblockspam.com/blog/email-thread-hijacking), or send mail as the user if the app asked for that permission.

### Which permissions should worry you?

Watch for apps asking to read or write mail, mailbox settings, files across all sites, contacts or calendars, especially from an unverified publisher. Microsoft's guidance is to look for permissions with "Read" and "Write" or "All" in them, and apps with "misspelled names, super bland names, or hacker-sounding names."

### What should users check on a consent screen?

The consent prompt itself carries the evidence, if people know where to look:

- **The app name and publisher.** Microsoft warns: "Don't rely on application names and domain URLs as a source of authenticity." Look for a [verified publisher](https://learn.microsoft.com/en-us/entra/identity-platform/publisher-verification-overview), and remember that even then you should check what's being asked for.
- **The permission list.** A PDF viewer has no reason to read all your mail, send mail as you, or access every file in the organization.
- **How you got there.** A consent prompt reached from an unexpected email link is the attack pattern. Apps you need are usually rolled out by IT, not discovered in your inbox.
- **Spelling and grammar.** Microsoft lists errors on the consent screen or in the email as a sign of a suspicious app. Users can report one with the **Report it here** link on the consent prompt, and Microsoft investigates and disables the app if it's confirmed malicious.

When in doubt, the safe answer is **Cancel** and a message to IT. A legitimate app can always be approved later.

## How do you restrict user consent in Entra ID?

By default, "all users are allowed to consent to applications for permissions that don't require administrator consent" ([Microsoft Learn](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/configure-user-consent)). Exactly what that covers depends on which consent setting your tenant uses:

| Setting | What users can approve | Notes |
|---|---|---|
| **Do not allow user consent** | Nothing; an admin must approve every app | Strictest. Pair it with the admin consent workflow |
| **Allow user consent for apps from verified publishers, for selected permissions** | Low-impact permissions you classify, for verified publishers and apps registered in your tenant | Microsoft's long-standing recommendation |
| **Let Microsoft manage your consent settings** | Any user-consentable delegated permission except a Microsoft-maintained list | The default for new tenants |
| **Allow user consent for apps** (legacy) | Any permission that doesn't need admin consent, for any app | Riskiest; common in older tenants |

The Microsoft-managed setting currently blocks user consent to permissions including `Mail.Read`, `Mail.ReadWrite`, `MailboxSettings.ReadWrite`, `Files.Read.All`, `Sites.Read.All`, `Contacts.ReadWrite` and `Calendars.Read`, plus legacy Exchange access such as `IMAP.AccessAsUser.All` ([Microsoft Learn](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/manage-app-consent-policies)). A separate default policy still lets users approve a short list of popular mail apps, such as Apple Mail and Thunderbird, for mail permissions.

To change the setting:

1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com) as a Global Administrator.
2. Go to **Entra ID** > **Enterprise apps** > **Consent and permissions** > **User consent settings**. (Some Microsoft pages still show the older path, **Identity** > **Applications** > **Enterprise apps**.)
3. Under **User consent for applications**, choose your setting and select **Save**.

For most small businesses, either the Microsoft-managed setting or **Do not allow user consent** plus the admin consent workflow is a sensible choice. If you're on the legacy setting, change it.

Changes only apply to future consents. Microsoft notes that "existing consent grants remain unchanged", so review existing grants as well (below).

## How do you set up the admin consent workflow?

Strict consent settings create friction. The admin consent workflow gives users a way to ask instead of hunting for workarounds ([Microsoft Learn](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/configure-admin-consent-workflow)).

1. In the Entra admin center, go to **Entra ID** > **Enterprise apps** > **Consent and permissions** > **Admin consent settings**.
2. Set **Users can request admin consent to apps they are unable to consent to** to **Yes**.
3. Under **Who can review admin consent requests**, add the people or roles who will review.
4. Turn on **Selected users will receive email notifications for requests** and **Selected users will receive request expiration reminders**.
5. Set **Consent request expires after (days)** and select **Save**. Microsoft says it "can take up to an hour" to take effect.

When you review a request, check the publisher, whether it's verified, every permission requested and whether the app does something your business actually needs.

## How do you review and revoke app grants?

### Find consent events

Search the audit log in the Microsoft Defender portal (`https://security.microsoft.com/auditlogsearch`) and sort for the activity **Consent to application**. Open each entry and check whether `IsAdminConsent` is `True`, which means the grant covers the whole organization. Audit entries can take 30 minutes to 24 hours to appear. In a larger tenant, Microsoft suggests reviewing consent grants weekly.

### Review an app's permissions

1. In the Entra admin center, go to **Entra ID** > **Enterprise apps** > **All applications** and select the app.
2. Select **Permissions**.
3. The **Admin consent** tab shows organization-wide grants. The **User consent** tab shows grants by individual users.
4. To remove an admin grant, select the **...** next to the permission and choose **Revoke permission**.

To see what one user approved, go to **Entra ID** > **Users** > **All users**, select the user and open **Applications**. Users can also review and remove their own apps at `myapps.microsoft.com`.

### Revoke user grants with PowerShell

The portal can't revoke grants on the **User consent** tab. Use Microsoft Graph PowerShell, based on [Microsoft's example](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/manage-application-permissions):

```powershell
Connect-MgGraph -Scopes "Application.ReadWrite.All","DelegatedPermissionGrant.ReadWrite.All","AppRoleAssignment.ReadWrite.All"

$sp = Get-MgServicePrincipal -ServicePrincipalId "<service principal object ID>"

# Remove every delegated (user or admin) permission grant for this app
Get-MgOauth2PermissionGrant -All |
    Where-Object { $_.ClientId -eq $sp.Id } |
    ForEach-Object { Remove-MgOauth2PermissionGrant -OAuth2PermissionGrantId $_.Id }
```

Revoking a grant "doesn't stop users from re-consenting to the application's requested permissions", so tighten the consent setting too. For an active incident, Microsoft also suggests disabling sign-in for the affected account as a short-term step.

### Work out what the app touched

Search the audit log for the affected users across the period the app had access. Microsoft notes this needs mailbox auditing and activity auditing turned on before the attack. If the app could read mail, assume conversations about payments were exposed and warn the relevant suppliers and customers by phone.

## How does this fit with your other defenses?

Consent phishing is one of several ways into a mailbox that skip the password. Treat it as part of your [compromised account response](https://iblockspam.com/blog/signs-email-account-compromised): every incident checklist should include "review app consents" alongside "revoke sessions" and "check [inbox rules and forwarding](https://iblockspam.com/blog/malicious-inbox-rules-auto-forwarding)."

The lure still arrives by email, usually as a document-sharing or sign-in request. Filtering phishing before it reaches the inbox, and teaching staff that a genuine-looking Microsoft consent screen can still be a trap, reduces how often anyone sees the **Accept** button at all. Microsoft's own guidance adds: "Don't rely on application names and domain URLs as a source of authenticity."

## Next steps

1. Open **User consent settings** today and confirm you're not on **Allow user consent for apps**.
2. Turn on the admin consent workflow and name at least two reviewers.
3. Review the **User consent** grants on your enterprise apps and revoke anything nobody recognizes.
4. Reduce the phishing that delivers consent links. iBlockSpam filters phishing and spoofing at the MX before mail reaches Microsoft 365; see [iBlockSpam for Microsoft 365](https://iblockspam.com/platforms/microsoft-365).

Browse our other [phishing and threat guides](https://iblockspam.com/blog/topic/threats).

## Frequently asked questions

### Does resetting the password remove a malicious OAuth app?

No. Microsoft says normal remediation steps such as resetting passwords or requiring MFA "aren't effective against this type of attack, because these apps are external to the organization." The app holds its own permission grant. You have to revoke that grant, and stop users consenting to it again, before its access ends.

### Can users in my tenant approve apps without an admin?

By default, yes, for permissions that don't need admin consent. New tenants get the Microsoft-managed setting, which currently blocks user consent to sensitive mail, file, calendar, chat and contact permissions. Older tenants may still use the legacy setting that lets users approve any app for any user-consentable permission. Check User consent settings in Entra.

### What is the admin consent workflow?

It lets a user who can't approve an app send a request to designated reviewers instead of hitting a dead end. Reviewers get an email, check the app and its permissions, then approve, deny or block it. It makes strict consent settings workable, because people have a legitimate route to get tools they need.

### How do I see which apps users have approved?

In the Microsoft Entra admin center, open Entra ID, Enterprise apps, All applications, select an app and choose Permissions. The User consent tab lists grants individual users made. You can also search the audit log for Consent to application events, or ask users to review their own apps at myapps.microsoft.com.

### Does Microsoft remove malicious apps itself?

When Microsoft confirms an app violates its terms, it disables the app across its services and emails a Privileged Role Administrator in tenants where users had consented. New tokens are refused, but Microsoft notes existing access tokens stay valid until they expire. You still need to investigate what the app accessed.

## Sources

- [Microsoft Learn: Protect against consent phishing](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/protect-against-consent-phishing)
- [Microsoft Learn: Detect and remediate illicit consent grants](https://learn.microsoft.com/en-us/defender-office-365/detect-and-remediate-illicit-consent-grants)
- [Microsoft Learn: Configure how users consent to applications](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/configure-user-consent)
- [Microsoft Learn: Manage app consent policies](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/manage-app-consent-policies)
- [Microsoft Learn: Configure the admin consent workflow](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/configure-admin-consent-workflow)
- [Microsoft Learn: Review permissions granted to enterprise applications](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/manage-application-permissions)

## Free tools for this guide

- [Email Header Analyzer](https://iblockspam.com/tools/email-header-analyzer): Trace hops and authentication results — runs entirely in your browser.
- [Email Health Check](https://iblockspam.com/tools/email-health-check): Grade your domain's MX, SPF, DKIM, DMARC and transport security in one scan.

---

Source: iBlockSpam, https://iblockspam.com/blog/oauth-consent-phishing-microsoft-365 (this is a Markdown copy; the HTML page is canonical). Quote with attribution and a link. Site index for AI assistants: https://iblockspam.com/llms.txt