OAuth Phishing Turns MFA Into a Bypass

How the attack works

OAuth phishing does not try to steal a password directly. Instead, it abuses legitimate sign-in and consent flows so the victim authenticates through a real identity provider while the attacker ends up with the resulting access token or consent grant. Because the sign-in itself is genuine and MFA is completed normally, the attacker gains durable access that can survive a password reset unless the underlying refresh token is explicitly revoked.

Three practical paths show up in this attack pattern:

• Device authorization abuse, where an attacker requests a device sign-in code and persuades the victim to enter it on the real device-login page, unknowingly authenticating the attacker's session.
• Permission hijacking, where an application is registered with a vague or innocuous name and then requests permissions far beyond what that name implies.
• Malicious redirects, where an authorization URL is crafted to deliberately trigger an authentication error, causing the identity provider to append error parameters to the redirect URI and send the browser to an attacker-controlled page.

Why it succeeds

Each of these techniques relies on a trusted surface that users have learned to trust by default. A device-login page is real. A consent screen comes from a legitimate identity provider. A familiar brand name appears on the authorization request. None of these details actually verify that the requesting application or the person initiating the sign-in is legitimate, since the consent screen only shows the name provided at registration, not a verified identity.

What to watch for

• A device-login code that was not initiated by your own device or action.
• An application name that is vague, generic, or gives no real signal about its purpose, such as a security or privacy-sounding extension.
• A consent request asking for permissions that exceed what the application should reasonably need.
• A sign-in flow that produces an unexpected error, or a final destination that differs from the identity provider you started with.

Building resistance

Awareness should focus on treating the consent screen itself as the attack surface, not just the login page. Employees should be trained to never enter a device-login code or approve a sign-in unless they personally started that sign-in on a device they control, and to read consent screens carefully rather than clicking Allow by habit. A familiar brand name or a legitimate identity provider URL should not be treated as proof of legitimacy on its own. On the organizational side, restricting end-user application consent, requiring administrator approval for new app permissions, and regularly auditing redirect URIs and granted permissions can reduce the chance that one approved click leads to lasting account access. See the related techniques: T1528, T1550.001, and T1656 for more detail on how these token-based access methods are classified.

Can OAuth phishing really bypass MFA?

Yes. The victim completes authentication through a legitimate identity provider and satisfies MFA, but the attacker ends up with the resulting token or consent grant, giving them access without ever needing the password or MFA code directly.

Why doesn't a password reset stop this attack?

Refresh tokens can provide lasting access and may survive password resets unless an administrator explicitly revokes them.

What is device-code phishing?

An attacker requests a device sign-in code from a legitimate identity provider, then tricks the victim into entering that code on the real login page, unknowingly authenticating the attacker's session.

How can organizations reduce this risk?

Organizations should restrict end-user application consent, require administrator approval for new app permissions, and audit redirect URIs and granted permissions.