OAuth App Phishing: How Attackers Get Into Microsoft 365 Without Stealing a Password

Every small business has spent the last few years training employees to spot the same thing: a fake login page asking for a username and password. That training is worth keeping, but it quietly created a blind spot. Attackers know phishing-resistant MFA and password managers have made credential theft harder, so a growing share of attacks now skip the password step entirely and go straight for something an employee will approve without a second thought: an app permission request.

How the attack actually works

The email looks routine. It might claim to be a shared-document notification, a new productivity add-in, or a security tool your IT provider is rolling out. Clicking through leads not to a fake login page, but to the real Microsoft or Google consent screen, because the app really is registered with Microsoft or Google, just by the attacker. The employee sees a legitimate-looking prompt asking to let the app read their email, access their files, or sign in as them, and clicks Accept the same way they'd accept a calendar invite. No password is typed. No MFA code is requested. The account was never technically "hacked."

Why this slips past every control built for password theft

Multi-factor authentication, conditional access policies, and password managers all defend the login step. OAuth consent phishing doesn't touch the login step. The employee authenticates as themselves, using their own credentials and their own MFA, and then separately grants a permission to an app. From the identity provider's point of view, nothing suspicious happened: a real user, on a real session, approved a real-looking request. The resulting access token can read mail, search files, or send email as that user, and it typically survives a forced password reset, since a reset changes the credential, not the grant. Someone has to go find the app registration and revoke it directly.

Why small businesses are an easier target than they think

Most small Microsoft 365 and Google Workspace tenants are configured with default settings that let any employee consent to any app requesting standard permissions, with no admin review required. Nobody set it up that way on purpose; it's simply what ships out of the box, and almost no small business has ever visited the screen that controls it. That means the only thing standing between a normal inbox and a compromised one is a single employee's judgment about whether an app permission prompt looks legitimate, on a busy day, in a design attackers have gotten very good at imitating.

Closing the gap without a security team

• Review what's already connected. In Microsoft 365, check Enterprise Applications in the Entra admin center; in Google Workspace, check Security > API Controls > App Access Control. Remove anything nobody remembers approving.
• Restrict user consent for new apps. Require admin approval for apps requesting anything beyond basic sign-in, instead of leaving it open to every employee by default.
• Set up periodic reviews, not a one-time cleanup. New apps get connected constantly as employees try new tools; a quarterly look at the list catches what slips through.
• Fold it into security awareness training. Employees who already know to distrust a fake login page usually haven't been shown what a malicious consent prompt looks like, because almost nobody has told them it exists.

None of this requires new software or a dedicated security hire. It requires someone spending twenty minutes in an admin console that most small businesses have never opened, and changing one default setting most small businesses never knew was on.

Where this fits

• The identity hardening post, for the broader set of Microsoft 365 identity controls this one adds to.
• The MFA fatigue post, for another way attackers route around multi-factor authentication instead of breaking it.
• The business email compromise post, for what an attacker typically does once they're sitting inside a compromised mailbox.
• The browser extension security post, for the closest cousin of this risk at the device level instead of the account level.
• The cybersecurity page, for the underlying identity and email controls that reduce this exposure overall.

FAQs about OAuth app phishing

If we already require MFA, are we protected from this?

No, and that's the point. OAuth consent phishing doesn't try to steal a password or a one-time code at all, so multi-factor authentication never gets a chance to trigger. The employee is genuinely logged in as themselves when they approve the request; they're just handing a token to an app they shouldn't trust. MFA remains essential for stopping password-based attacks, but it does nothing here.

How do I know what apps already have access to our Microsoft 365 or Google Workspace?

In Microsoft 365, an admin can review every registered app and its granted permissions under Enterprise Applications in the Entra admin center. In Google Workspace, the equivalent list is under Security > API Controls > App Access Control. Most small businesses have never opened either screen, and it's common to find five or ten apps with access nobody remembers approving.

Is this different from the risk of a malicious browser extension?

Yes. A browser extension runs on one employee's device and reads what happens in that browser. An OAuth app grant lives at the cloud account level, follows the user to any device, and keeps working even after a password reset, until someone explicitly revokes it. It's a smaller attack surface to create but a harder one to notice and a harder one to fully shut off.