OAuth Consent Attacks: Bypassing MFA with Phishing

OAuth Consent Phishing Is the MFA Bypass Nobody Talks About Enough

OAuth consent phishing has quietly become one of the most effective ways attackers steal access to cloud accounts, and it completely sidesteps MFA. The attack doesn't need your password. It doesn't need your one-time code. It needs you to click "Allow" on a permissions dialog that looks completely legitimate, because in many cases, the OAuth flow itself is legitimate. That distinction matters.

Traditional phishing steals credentials. This attack steals delegated authorization. Once a user grants consent to a malicious OAuth application, the attacker holds a valid access token issued by the identity provider. MFA already happened. The session is already authenticated. There is nothing left to intercept.

How the OAuth Consent Attack Actually Works

The mechanics are straightforward. An attacker registers a malicious application with a legitimate cloud platform, typically Microsoft 365, Google Workspace, or GitHub. They craft a phishing email that links to a real OAuth authorization endpoint, using their own client ID. The URL looks clean. The domain is genuinely microsoft.com or accounts.google.com.

The victim authenticates normally, completes MFA, then lands on the consent screen asking for permissions like "Read your email" or "Access your files." If they approve, the attacker's application receives a refresh token. That token persists across sessions, password resets, and even MFA re-enrollment. The attacker can quietly read email, exfiltrate files, or forward messages for months.

This technique has names in the industry. Microsoft calls variants of it "illicit consent grant attacks." Security researchers also call it OAuth phishing or app-based phishing. The core mechanism is the same regardless of the label.

What Developers and Admins Are Actually Risking

For developers building on OAuth, the risk cuts two ways. Your users can be targeted through third-party app consent flows. Your own application can be impersonated if your client registration details leak or if attackers create similarly named apps.

Persistent access is the real problem. A stolen password gets rotated. A revoked MFA device gets replaced. But an authorized OAuth application sitting quietly in a user's account, with a valid refresh token, keeps working until someone explicitly audits connected apps and revokes it. Most users never do that audit.

Enterprise environments running Microsoft 365 are particularly exposed because the default tenant configuration historically allowed users to consent to third-party apps without admin approval. Many organizations haven't tightened that setting.

How to Defend Against OAuth Consent Phishing

Restrict user consent. In Microsoft Entra ID (formerly Azure AD), set the user consent policy to require admin approval for any application requesting permissions. Google Workspace has equivalent controls under API controls in the Admin Console. This single change kills most opportunistic OAuth phishing campaigns.

Audit existing connected applications. Pull a report of all OAuth apps that have been granted access in your tenant. Look for apps with broad permissions, low user counts, or names that don't match known vendors. Revoke anything suspicious immediately.

Deploy Conditional Access or context-aware access policies that flag or block token usage from unusual locations, even after consent has been granted.

For developers, implement the principle of least privilege in your own OAuth scopes. Request only what you need. Narrow scopes reduce the blast radius if your application is ever abused. You can also read more about securing web application authentication flows on the VibeWShield blog.

Monitor for token refresh activity outside business hours or from unexpected IP ranges. This is often the first signal that a consent grant has been abused.

Is MFA completely useless against OAuth phishing? MFA still protects against credential theft. The problem is that OAuth consent attacks happen after authentication completes. MFA did its job. The attack exploits the authorization layer, not the authentication layer.

Can I detect if my account has already been compromised this way? Yes. In Microsoft 365, check "My Apps" at myapps.microsoft.com or have an admin run the Oauth App audit in Microsoft Defender. In Google, review third-party app access at myaccount.google.com/permissions.

How do attackers register apps on legitimate platforms without getting caught? Registration requires only a developer account, which is free and low-friction on most platforms. Attackers use disposable accounts, generic app names, and legitimate-looking privacy policy URLs to pass basic automated checks.

Run a free scan of your web application at VibeWShield to identify OAuth misconfigurations and other authentication vulnerabilities before attackers do.