OAuth Consent Phishing: The ‘Allow Access’ Click That Hands Over Your Email

The Click That Skips the Password Entirely

Most phishing training focuses on fake login pages designed to steal a password. OAuth consent phishing doesn’t bother with any of that — it sends your employee to the real Microsoft or Google login page, lets them authenticate completely legitimately, MFA and all, and then asks them to click “Allow” on a permissions screen. That one click hands a malicious application ongoing access to their email, files, or calendar — and because no password was ever stolen, a password reset afterward does nothing to remove the attacker.

How the Attack Actually Works

The mechanics are what make this attack genuinely dangerous rather than just another phishing variant:

• The attacker registers a real OAuth application in Microsoft Entra ID or Google’s developer platform — often with a name designed to look like a legitimate productivity tool or vendor integration.
• A phishing message directs the victim to a genuine authorization page — not a fake login clone, but the real microsoft.com or accounts.google.com sign-in flow. This is why the attack slips past employees trained to check for lookalike domains.
• The victim signs in completely normally, including MFA, because they’re authenticating to the real identity provider.
• A consent screen appears, listing the permissions the application is requesting — things like Mail.Read, Files.ReadWrite.All, or Sites.FullControl.All. Most employees have no framework for evaluating whether these specific permission names are reasonable for the app in front of them, and click Allow.
• The identity provider issues an access token directly to the attacker’s application — which can now read email, access files, or take other actions as that user, on an ongoing basis, without ever knowing the victim’s password.

Why MFA and Password Resets Don’t Fix It

This is the detail that catches security-conscious businesses off guard: MFA protects the sign-in step, not the authorization step that comes after it. Once consent is granted, the attacker holds a valid access token completely independent of the user’s password. Resetting the password doesn’t revoke it. The only way to cut off access is to find the malicious application’s specific grant and revoke it directly — which most small businesses have no process for even checking.

Defenses That Actually Work

Because this attack routes around password and MFA defenses entirely, the fix has to happen at the application-consent layer:

• Restrict user consent for high-risk permissions. Configure Microsoft 365 / Entra and Google Workspace to require admin approval before any application can request sensitive scopes (mail access, full file access, directory access) — don’t leave this at the default of letting any user grant any app any permission.
• Set up an admin consent workflow. Instead of blanket-blocking every new app request, route them to an admin for a quick review, so legitimate business tools still get approved without every user having unilateral authority to grant broad access.
• Review your existing OAuth app grants quarterly. Most organizations have never looked at what third-party apps their employees have already authorized. Pull the list, and revoke anything unused, unrecognized, or requesting more access than its stated purpose justifies.
• Limit who can authenticate to high-privilege first-party tools like Azure CLI or PowerShell, since these carry elevated trust and are a common target once an attacker has a foothold.

Train Your Team on the Consent Screen, Not Just the Login Page

Traditional phishing training teaches people to scrutinize URLs and sender addresses. Add one more instinct: treat an unexpected “This app is requesting permission to…” screen with the same suspicion as an unexpected password prompt, especially for an app they didn’t intentionally set out to install. If the permissions being requested don’t obviously match what the app claims to do, that mismatch is the red flag.

How to Check What’s Already Been Granted

Most small businesses have never actually looked at what third-party applications their employees have already authorized — and that list is usually longer and older than anyone expects, full of apps connected during a free trial, a one-time integration, or a forgotten side project. In Microsoft 365, admins can review this under Entra ID > Enterprise Applications, which lists every app with delegated permissions across the organization. In Google Workspace, it’s under Security > API Controls > App Access Control in the Admin console. Run this review now, not after an incident — revoke anything you don’t recognize, anything no longer in active use, and anything requesting broader permissions than its stated purpose reasonably requires.

Real-World Pattern: How These Attacks Usually Arrive

OAuth consent phishing campaigns often ride along with a business trend rather than a generic phishing blast — a fake “AI meeting assistant” or “document collaboration tool” invite is a common current lure, since employees are primed to click through new productivity app invitations without much scrutiny. The email often looks like it’s coming from a colleague (“I’ve shared a document with you” or “Join my meeting notes app”), which lowers guard further than a cold outreach would. Because the resulting authorization page is genuinely hosted on Microsoft or Google’s real domain, employees who’ve been trained to check for spoofed login pages often report feeling confident the request was legitimate right up until the account starts sending phishing emails to the rest of the company from the inside.

A Close Cousin: Session Token Theft

OAuth consent phishing sits in the same family as session token theft that bypasses MFA — both attacks succeed specifically because they target what happens after a legitimate, fully-authenticated sign-in rather than trying to steal a password outright. If your team already has a small business incident response plan, make sure it explicitly covers “revoke an OAuth app grant” as a containment step, not just “reset the password” — the two attacks need different response playbooks, and defaulting to a password reset alone leaves this specific access path wide open. This is also a good moment to fold consent-screen scrutiny into your broader social engineering awareness training, since the psychological trick (a trusted-looking request that asks for one click) is the same pattern underlying most of these attacks.

Bottom Line

OAuth consent phishing bypasses the two controls most small businesses rely on most — strong passwords and MFA — by targeting a step neither one protects. Locking down who can grant application permissions, reviewing existing grants regularly, and teaching employees to scrutinize consent screens the same way they scrutinize login pages closes a gap that a lot of otherwise well-secured small businesses have never even looked at.