Consent Phishing: Definition, How It Works, and How to Spot It

Consent phishing is an OAuth phishing technique where attackers trick a user (or admin) into clicking Accept on an OAuth consent screen, granting a malicious OAuth app access to email, files, or directory data via tokens—often without stealing a password. Because access is “authorized,” it can slip past controls that are tuned for credential theft, making consent phishing a high-impact identity security risk in Microsoft 365/Entra ID and Google Workspace environments.

How consent phishing works (step-by-step)

Consent phishing abuses legitimate “Sign in with…” and app authorization flows. The attacker’s goal is not to steal credentials directly, but to get the victim to authorize an application the attacker controls.

1) The attacker creates a convincing OAuth app

The attacker registers an OAuth/OIDC application in a cloud identity platform (common targets: Microsoft Entra ID/Azure AD for Microsoft 365, Google Cloud for Google Workspace). The app is given a friendly name, logo, and publisher info that looks trustworthy (e.g., “DocuSign Viewer,” “HR Portal,” “Invoice Processor”).

They request permissions (“scopes”) that provide value to an attacker, such as:

• Read mail, send mail, access contacts/calendar
• Read/modify files in cloud storage
• Read user profile / directory info
• Offline access / refresh token capability (persistence)

2) The victim is lured to a real OAuth consent screen

Delivery usually looks like standard phishing:

• “You received a secure document — view now”
• “Action required: payroll update”
• “New voicemail — listen”
• “Shared file awaiting approval”

The link opens a real authorization/consent page hosted by the identity provider. This is why the attack is effective: users see a familiar domain and a legitimate login + consent flow.

3) The victim grants consent (clicks “Accept”)

If the victim clicks Accept, the identity provider issues tokens to the malicious app based on the granted permissions. Depending on the platform and configuration:

• The attacker receives an authorization code redirected back to their app
• The app exchanges it for access tokens (and often refresh tokens)
• The attacker can call APIs (e.g., Microsoft Graph, Google APIs) as the user

Crucially, the attacker may not need the password at all. If the victim is already signed in, the consent page may present only an “Accept permissions” prompt.

4) The attacker accesses data and establishes persistence

With tokens in hand, the attacker can:

• Read emails and search for invoices, password resets, MFA prompts, or sensitive threads
• Send emails as the user (internal spearphishing/BEC-style scams)
• Access files and shared drives
• Enumerate org info to plan deeper attacks

Persistence often comes from:

• Refresh tokens / offline access (long-lived access without repeated user interaction)
• The consent grant remaining valid until explicitly revoked
• “Consent once, access many times” behavior across services

5) Optional: high impact via admin consent

If an admin is tricked into granting org-wide permissions (“admin consent”), the malicious app can access data across many users, depending on scopes and platform protections.

Why consent phishing is different from classic phishing

• The attacker leverages authorized access, not unauthorized access.
• MFA and Conditional Access may not stop it if the user can legitimately authenticate and then approve consent.
• The “malicious artifact” is often an OAuth app registration + consent grant, not malware on an endpoint.

Indicators of consent phishing (what to hunt for)

Common high-risk permission patterns (names vary by platform) include:

• Mail read/write or send permissions
• Files read/write permissions
• Offline access / refresh token scopes
• Broad directory permissions (especially if admin-consented)

Operational clues:

• New OAuth app with a lookalike name
• Recently granted consent by a user who rarely installs apps
• Consent grants clustered around a phishing campaign timeframe
• API access from unusual IPs/ASNs shortly after consent

Example log-hunting starting points (illustrative; adapt to your platform/SIEM):

Look for:
- "Consent to application" events
- "Admin consent" events
- New service principal / enterprise app created
- OAuth token issuance followed by Graph/API calls from atypical locations

Where you’ll encounter consent phishing

Consent phishing shows up anywhere identity and SaaS ecosystems rely on OAuth and app integrations.

Microsoft 365 / Entra ID environments

You’ll encounter consent phishing when:

• Users receive email lures that point to Microsoft login and then an OAuth consent screen
• “Enterprise applications” appear that no one recognizes
• Mailbox access happens via Microsoft Graph rather than legacy IMAP/SMTP

It’s particularly common in organizations where users are allowed to consent to apps by default.

Google Workspace environments

Typical encounters:

• A user is prompted to “Allow” an app to access Gmail/Drive
• A suspicious app appears in “Third-party apps with account access”
• OAuth grants appear for apps outside your normal vendor set

Any organization using SSO/OAuth for SaaS

Even outside Microsoft/Google, many SaaS tools support OAuth-based access to email, calendars, or storage. Consent phishing appears as:

• A new integration “connected” to a user’s account
• Unexpected API-driven activity (email sends, file reads) without corresponding UI activity
• Helpdesk tickets like “I clicked Allow and now things are weird”

During BEC, invoice fraud, and internal spearphishing

Attackers often use consent phishing as a stealthy foothold to:

• Monitor invoices and payment instructions
• Insert themselves into finance threads
• Send convincing emails from the compromised user to vendors or colleagues

Because the access is token-based and “authorized,” it can bypass some controls that are tuned for password theft.

How to prevent consent phishing (practical defenses)

Restrict user app consent (best ROI control)

• Disable end-user consent where feasible.
• Require admin approval for apps requesting high-risk scopes.
• Allow only verified publishers / pre-approved apps.

If you need a complementary control mindset, treat OAuth app permissions like any other policy enforcement problem—tight scoping, review gates, and monitoring. (Related reading: how to secure open policy agent opa deployments)

Audit OAuth apps and consent grants regularly

• Review recently added enterprise apps / OAuth clients.
• Identify apps with mail/files scopes.
• Remove or block unknown apps; revoke grants.

Alert on suspicious consent events

• Create SIEM detections for new consent grants, especially for high-privilege scopes.
• Alert on admin consent events immediately.

To standardize how you record and communicate weaknesses discovered during these reviews, map findings to common classifications where appropriate. (See: what is cwe)

Incident response: revoke tokens and remove the app

When you suspect consent phishing:

1. Revoke the user’s sessions/tokens.
2. Remove the app’s access (revoke consent / delete enterprise app).
3. Reset affected credentials if there’s any chance of credential capture as well.
4. Review mailbox rules, forwarding, and unusual sends (attackers may pair techniques).

User-facing ways to spot a malicious OAuth consent prompt

Even though the page is legitimate, the request may not be:

• The app name/publisher is unfamiliar or slightly “off.”
• The permissions look excessive for the stated purpose (e.g., “read and send email” to “view a document”).
• The message is urgent and transactional (“invoice,” “wire,” “payroll,” “legal doc”).
• The app requests offline access / “maintain access when you’re not using the app.”

If in doubt, deny the request and confirm with IT/security via an out-of-band channel.

Recommended tools (optional, defense-in-depth)

Consent phishing is primarily an identity/app-permissions problem, but endpoint and account hygiene still reduce overall risk and speed response:

• A reputable password manager can help reduce reuse and improve account hygiene across SaaS (e.g., 1Password: Try 1Password →).
• Malware scanning and cleanup can help when consent phishing is paired with other access techniques (e.g., Malwarebytes: Get Malwarebytes →).
• When users work on untrusted networks, a VPN can reduce opportunistic interception risks (though it won’t prevent OAuth consent abuse): NordVPN Check NordVPN pricing → or Surfshark Try Proton VPN →.