.webp)
You turned on multi-factor authentication. Your team completed the training. You can check that box. And then someone's Microsoft 365 account gets compromised without a single password being stolen, without triggering an MFA prompt, and without producing a sign-in event that looks like anything went wrong.
That's not a hypothetical. It's how OAuth consent phishing works, and it's been quietly emptying business email accounts, SharePoint libraries, and cloud file stores throughout 2026. The technique doesn't attack your password or your MFA. It attacks the layer below both of them - the OAuth token system that Microsoft 365 (and most modern cloud applications) are built on.
If your business runs on Microsoft 365, this is worth understanding. Here's what's happening, why it bypasses your current controls, and what to do about it.
How OAuth Works - and Why It Can Be Turned Against You
When you click "Sign in with Microsoft" on a third-party app, you don't give that app your password. Instead, Microsoft issues it an OAuth token - a signed key that says the app can access specific parts of your account (your email, your calendar, your files) on your behalf. This is intentional. It's the mechanism that lets Zoom read your calendar or DocuSign access your mailbox without you sharing credentials.
OAuth tokens come in two types: access tokens (short-lived, usually an hour) and refresh tokens (longer-lived, used to get new access tokens without re-authenticating). The refresh token is the one attackers want. Get one of those, and you have persistent access that survives password resets.
Here's the critical detail: your MFA is not involved when a refresh token is used. You authenticated once. MFA fired once. The token that came out of that authentication can be reused from anywhere in the world - and none of those subsequent accesses look like a new login to your monitoring systems.
What OAuth Consent Phishing Actually Looks Like
The attack doesn't require sophisticated technical infrastructure. Here's a typical flow.
An employee gets a message - email, Teams, even a text - asking them to verify their account or approve a shared document. The link takes them to a real Microsoft login page. They enter their credentials and complete the MFA prompt on their actual phone. Everything looks legitimate because it is legitimate. Microsoft is handling the authentication on its own servers.
What's buried in the flow is a consent screen. The user sees something like: "This app would like to read your email, access files when you're not present." They click Accept. That's it. They just handed an attacker a refresh token scoped to their mailbox and OneDrive - one that will remain valid for weeks or months depending on how the tenant is configured.
The attacker never saw the password. The MFA challenge passed on real Microsoft infrastructure. No suspicious sign-in event fires. The token works exactly as designed by the protocol.
Earlier this year, a phishing-as-a-service platform built on this technique was documented by the Cloud Security Alliance. Within weeks of launch it had compromised more than 340 Microsoft 365 organizations across five countries, according to The Hacker News. The targets weren't large enterprises with complex security stacks. They were organizations that had MFA turned on and assumed that was sufficient.
Why Resetting the Password Doesn't Fix It
The standard incident response when a phish is suspected: reset the password, force re-authentication, move on. With credential phishing, that works. With OAuth consent phishing, it doesn't.
A refresh token is not tied to the password. Microsoft issues it based on a successful authentication event. Changing the password afterward doesn't invalidate tokens that were already issued. The attacker's token keeps working until someone explicitly revokes all OAuth grants for that account - or until a Conditional Access policy forces re-consent.
This is why incident response for OAuth phishing needs a different playbook: token revocation first, then password reset, then audit of what the token accessed during the window it was active.
The Consent Normalization Problem
The reason this attack is effective isn't a flaw in OAuth. It's a flaw in behavior that attackers deliberately exploit.
Most Microsoft 365 users see OAuth consent screens regularly. Every new integration - a project management tool, an AI assistant, a browser extension - asks for consent. The screens look the same. Users have been trained, by repetition, to click Accept. Evaluating whether a specific scope like "Access your files when you're not present" represents acceptable risk is hard when you see legitimate consent requests 10-15 times in a normal month.
Attackers craft consent requests that look like the legitimate integrations employees already approve. The scopes use Microsoft's own language. The experience is indistinguishable from onboarding a new business tool. That's the whole point.
How to Lock This Down in Your Microsoft 365 Tenant
The good news: Microsoft gives administrators real controls over OAuth consent. Most small businesses have never touched these settings because the defaults prioritize ease of use over security. Here's what to change.
Restrict User Consent to Verified Publishers
In the Microsoft Entra admin center (formerly Azure Active Directory), navigate to Enterprise Applications, then Consent and Permissions. Change the default user consent setting from "Allow users to consent to all apps" to "Allow user consent for apps from verified publishers, for selected permissions." This means employees can still consent to Microsoft-verified integrations but can't approve requests from unrecognized third-party apps.
For most small businesses, requiring admin approval for all third-party app consent is even better. It adds a step, but so does recovering from a compromised account.
Enable the Admin Consent Workflow
When users hit an app that requires consent beyond what they're allowed to self-approve, they should be able to request it rather than just see an error. Enable the admin consent workflow in Entra so those requests route to your IT admin or managed services provider for review. This keeps employees unblocked while keeping your IT team in control of what gets granted.
Audit Existing OAuth Grants
Before hardening new consent, check what's already been granted. In the Microsoft 365 admin center, you can review OAuth grants under Azure Active Directory, Enterprise Applications, All Applications (filter by user-assigned). Look for apps with broad scopes - mail read/write, files read/write offline access - that aren't recognized business tools.
Microsoft's OAuth app investigation tool in Defender for Cloud Apps surfaces high-risk grants automatically and flags apps that have unusual permission combinations. If you're not using Defender for Cloud Apps, your IT provider should be.
Block the Device Code Flow for Standard Users
The OAuth device code flow is designed for devices without keyboards - smart TVs logging into streaming services, for example. If your business doesn't have that use case, Conditional Access can block legacy and alternative authentication flows for standard user accounts. This removes one of the most commonly exploited OAuth attack paths without affecting normal M365 usage.
Set Appropriate Token Lifetime Policies
Microsoft's default refresh token lifetime is configurable. For accounts with access to sensitive data - finance, HR, executive - shortening the maximum inactive refresh token lifetime reduces the window an attacker has after a successful grant. This requires some familiarity with Entra token configuration, but it's a meaningful control for higher-risk accounts.
What Your Team Needs to Know
Technical controls handle most of this. But user awareness still matters, because determined attackers adapt to control gaps - and an employee who recognizes a suspicious consent request is an extra layer of defense.
Train your team on these signals:
- Unexpected consent requests - if a legitimate integration your company already approved needs new scopes, IT would tell you first.
- Scopes that don't match the app's stated purpose - a "document viewer" that wants offline access to your mailbox is asking for more than it needs.
- Requests arriving via unusual channels - a Teams message from an unfamiliar contact asking you to authorize a new integration.
- Any urgency framing around approving access - legitimate tools don't expire in the next 10 minutes.
The simple rule for employees: if something is asking you to click Accept on a Microsoft permissions screen and you didn't specifically initiate a new tool installation, stop and check with IT first.
Our security awareness training program covers OAuth and consent phishing in depth - including realistic simulations that help employees recognize these requests in context, not just in a classroom.
What a Managed IT Provider Should Be Doing Here
If you work with a managed IT provider, OAuth governance should be part of your standard Microsoft 365 security baseline. Specifically:
- Consent policies reviewed and hardened during onboarding
- Quarterly OAuth grant audits to catch grants that accumulated over time
- Monitoring for new high-risk app grants via Defender for Cloud Apps
- Token revocation explicitly included in phishing incident response procedures - not just password resets
Our managed cybersecurity services include Microsoft 365 tenant hardening as a standard component, covering consent configuration, Conditional Access policies, and ongoing monitoring for unusual OAuth activity. We also review the full picture - endpoints, network, identity - through our vulnerability management program to make sure gaps like this don't go undetected.
If you're not sure what your current consent settings look like, that's worth a quick check. We're happy to take a look and give you an honest read on where you stand. Reach out at burgitech.com/contact-us or call (949) 381-1010.
The Bigger Picture on MFA
OAuth consent phishing isn't an argument against MFA. MFA is still essential and stops the overwhelming majority of credential-based attacks. What it does argue for is thinking about security in layers: MFA plus restricted consent policies plus token monitoring plus security awareness. Any one of those alone has gaps. Together, they force an attacker to solve a much harder problem.
The organizations that got hit by the attacks documented earlier this year had MFA. The ones that didn't get hit had MFA and consent controls. That gap - not the presence of MFA, but the additional configuration layer - is what made the difference.
Identity security has moved beyond just protecting passwords. The tokens that passwords generate are now the target. Protecting those requires a different set of controls, and most small businesses haven't configured them yet. That's the gap worth closing right now.
Frequently Asked Questions
Does MFA protect against OAuth phishing?
Not directly. OAuth phishing uses a legitimate, MFA-completed login to generate an access token. The MFA challenge fires and passes on the real Microsoft infrastructure. What the attacker steals is the token that comes out of that authentication - and using that token later requires no additional MFA. Restricting which apps users can consent to, and monitoring existing grants, are the controls that actually address this attack.
How do I see what apps have OAuth access to our Microsoft 365 accounts?
In the Microsoft Entra admin center, go to Enterprise Applications, then All Applications, and filter by user assignment. You can see which applications have been granted access and what permissions they hold. Microsoft Defender for Cloud Apps provides a more detailed OAuth app dashboard that flags high-risk grants automatically. If you're not sure how to interpret what you find, an IT provider can walk you through it.
What should I do if someone on my team may have clicked an OAuth phishing link?
First, revoke all OAuth grants for that account in the Entra admin center under the user's profile - this is separate from a password reset and has to be done explicitly. Then review sign-in logs for access that occurred after the consent event, particularly from unusual locations or outside business hours. Check for email forwarding rules, auto-replies, and any SharePoint or OneDrive access that doesn't match normal usage patterns.
Does this affect Google Workspace too?
Yes. OAuth is a universal standard used by Google Workspace, Salesforce, Slack, and most cloud platforms. Google Workspace has equivalent consent controls in its Admin Console under Security and API Controls. That said, the attack platforms documented this year have primarily targeted Microsoft 365 because of its scale - the majority of small and mid-sized businesses run on it. The underlying technique applies to any OAuth-based system.
We have fewer than 25 employees. Is this really a concern for us?
Yes - small businesses are frequently targeted precisely because security controls tend to be thinner. The attacks documented this year did not discriminate by company size. What matters to attackers is whether your Microsoft 365 accounts hold valuable data - customer records, financial information, contracts - not how many employees you have. The configuration changes described above take a few hours to implement and don't require expensive software.
