OAuth Consent Phishing: Stealing Your Account Without Your Password

For most of phishing's history, the attack was about credential capture. Make a fake login page that looks like the real one, get the victim to type their password, then log in as them. Two-factor authentication broke a lot of those attacks; FIDO2 hardware keys broke more. The defensive picture got better through the late 2010s.

Then attackers stopped chasing passwords.

Modern identity providers — Google, Microsoft, GitHub, Apple — all support OAuth 2.0 for third-party app integration. Slack wants to read your calendar? Click Allow. Calendly wants to send mail on your behalf? Click Allow. Trello wants to attach Drive files? Click Allow. Each Allow click grants a third-party application an access token that lets it talk to your account directly, with scopes you authorized, on a schedule the app controls.

Once attackers realized that the Allow click was the actual decision point — and that legitimate-looking OAuth apps could be created by anyone with an Azure tenant or a Google Cloud project — they had a new attack class. It's now usually called consent phishing or illicit consent grants, and it has been actively exploited at scale since at least 2017.

What the Attack Looks Like

A typical OAuth consent phishing flow:

1. The attacker registers an OAuth app with a legitimate identity provider (Microsoft Entra ID, Google Cloud Console). They give it a plausible name — "Adobe Acrobat Sign," "DocuSign Cloud," "Office 365 Reports," "Mail Compliance Check."
2. The app requests broad scopes — Mail.ReadWrite, Mail.Send, Files.ReadWrite.All, offline_access. Microsoft and Google show these in the consent screen, but in technical language users skim past.
3. The attacker sends the victim a phishing email with a real link to the identity provider's consent page — login.microsoftonline.com or accounts.google.com — which then displays the attacker's app requesting permissions.
4. The victim authenticates normally to the legitimate identity provider. This is the part that is genuinely indistinguishable from a real sign-in. Their browser-stored credentials work. Their 2FA prompt is the real one. Their hardware key validates against the real Microsoft or Google domain. Everything looks correct because everything is correct from a credential-flow standpoint.
5. The victim clicks Allow on the consent screen, granting the attacker's app the requested permissions on their account.
6. The attacker now holds a refresh token — typically with offline_access, which means the token persists indefinitely until manually revoked. They can read mail, send mail, access cloud files, on their own schedule.

The Real Cases

This is not theoretical. Documented campaigns include:

• The 2017 Google "Docs" worm — A malicious app called "Google Docs" requested access to victims' Gmail and contacts. Once granted, it emailed the same lure to every contact. Google removed the app within hours, but not before an estimated million accounts were affected.
• Microsoft 365 consent phishing campaigns documented by the Microsoft Threat Intelligence Center (2020 onward). Attackers create apps impersonating legitimate enterprise software and target executives by email. Victims grant Mail.ReadWrite + offline_access; the attacker proceeds with business email compromise.
• The "PerfectData Software" campaign (2022) — A consent-phishing operation targeting hundreds of Microsoft 365 tenants. The attacker app harvested email contents and forwarded high-value messages to attacker-controlled inboxes.
• The 2020 SANS Institute breach — An employee clicked Allow on a malicious "Enable4Excel" OAuth app, granting it access to mail and contacts. The attacker then forwarded thousands of emails over several weeks.

Why It Works on Smart Users

The standard advice for phishing — check the URL, look for spelling mistakes, hover over links — does not catch consent phishing reliably:

• The consent URL is real. It is genuinely on accounts.google.com or login.microsoftonline.com, with a valid TLS certificate from the actual identity provider.
• The login flow is real. If you have password-manager autofill set up for Google, it works. If your hardware key challenges the domain, it succeeds.
• The app name is plausibly legitimate. "Adobe Acrobat Sign" or "Microsoft Compliance Center" sound exactly like things your IT department might deploy.
• The publisher verification is weak. Microsoft has "Publisher verified" status but most legitimate apps in the wild don't have it; users have learned to ignore the absence of verification.
• The scope text is dense. "Read and write access to your mail" appears in a list of bulleted permissions that users skim. The actual implication — "this app can read every email you have and send mail as you indefinitely" — is not foregrounded.

Detection Is Harder Than It Should Be

Even after the grant, detection is slow:

• The attacker's API calls come from cloud IPs that look like legitimate SaaS traffic.
• No suspicious login alert fires — the user did the login, the attacker did not.
• The mail forwarding can be done via API without setting up server-side forwarding rules that admin dashboards monitor.
• Refresh tokens silently regenerate access tokens; revocation requires explicit admin action.

Microsoft and Google both publish guidance on monitoring for risky OAuth consent grants, and Microsoft's Defender for Cloud Apps now flags suspicious app behavior. But the detection bar is post-grant: damage is already done by the time admins notice.

What Actually Defends

Defense	Effectiveness
Admin consent required for any app requesting sensitive scopes	High — users can't grant Mail.ReadWrite without an admin reviewing the app first
Restrict third-party app registration to verified publishers only	High — eliminates the bulk of opportunistic consent phishing
Block legacy authentication protocols (IMAP/POP with password)	Moderate — closes related credential-phishing paths, not consent phishing directly
User training on OAuth consent dialogs	Moderate — useful as one layer, but consent dialogs are designed to look mundane
Periodic audit of granted OAuth permissions	Detection, not prevention — but reduces dwell time
Conditional Access policies limiting where tokens can be used	High — even a stolen token is constrained to IP ranges and device states

What to Do as an Individual

If you're not the admin of your account, the levers are smaller but real:

1. Audit your authorized apps regularly. Google: myaccount.google.com → Security → Third-party apps with account access. Microsoft: myapps.microsoft.com. Revoke anything you don't actively use.
2. Treat OAuth consent dialogs with the same scrutiny as installing software. If you clicked a link from an email and ended up here, the answer is almost always No, then go to the real app's documented sign-in flow.
3. Look at the publisher. Unknown publisher requesting Mail.ReadWrite is a strong "no."
4. Look at the scopes. A document-signing service does not need Mail.Send. A calendar tool does not need Files.ReadWrite.All.
5. If your organization uses Google Workspace or Microsoft 365, talk to your admin about restricting unverified-publisher OAuth apps. This is the single highest-leverage defense.

The strongest signal that an attack model has shifted is when the standard defenses stop working against the standard attacks. Consent phishing thrives precisely because the password-stealing playbook the industry built — 2FA, hardware keys, password managers — solves an attack the attackers are no longer running.

Where Haven Fits

Haven does not use OAuth federation for sign-in. Your account credentials are bound to a passphrase that derives keys locally and never leaves your device. There is no third-party-app permission to grant, no consent screen to phish, no refresh token to steal. Different threat model from Google or Microsoft, and the consent-phishing class of attack does not apply.

That doesn't make Haven invulnerable to phishing — nothing is — but it does mean we're not exposed to the specific exploit pattern that has eaten the last decade of corporate email security. For the broader question of how to think about phishing in a federated-identity world, see our piece on homograph and lookalike-domain phishing.