Consent phishing bypasses MFA by abusing OAuth trust in SaaS

At a glance

What this is: This is an analysis of consent phishing, a browser-based OAuth attack that uses legitimate permissions to bypass MFA and gain persistent SaaS access.

Why it matters: It matters because NHI and IAM teams must govern OAuth apps, tokens, and third-party connections as access paths, not treat them as benign integrations.

By the numbers:

• Security researchers tracked consent phishing campaigns affecting 900 tenants and 3,000 user accounts in 2025.
• Five major OAuth attack kits drove half of all device-code phishing traffic during autumn 2025.

👉 Read Obsidian Security's analysis of consent phishing and OAuth bypass techniques

Context

Consent phishing is an OAuth abuse pattern, not a password attack. It exploits the gap between authentication and authorization, which means a user can complete MFA on a legitimate login page and still hand an attacker durable access through a malicious app consent.

For IAM and NHI governance teams, the problem is the hidden trust layer between SaaS applications, where access tokens, delegated permissions, and first-party apps can operate outside normal authentication controls. That makes OAuth policy, visibility, and monitoring part of the identity perimeter, not an optional add-on. In this article's starting position, that is a typical blind spot in enterprise SaaS environments.

Obsidian Security frames consent phishing as a rapidly evolving threat with automated kits, device-code abuse, and browser-native variants such as ConsentFix. The operational lesson is straightforward: if an organization only watches for credential theft, it will miss a large share of real-world access abuse.

Key questions

Q: How should security teams handle OAuth consent in SaaS environments?

A: Security teams should treat OAuth consent as a privileged access decision, not a usability prompt. High-risk scopes need approval, app ownership, and periodic recertification. The practical goal is to control what a token can do after consent, because MFA and password resets do not remove an already issued bearer token.

Q: Why do MFA and password resets fail to stop consent phishing?

A: MFA and password resets protect authentication, but consent phishing abuses authorization after the user has already signed in. The attacker receives tokens from the legitimate flow, so the compromise survives credential changes until the app grant or refresh token is revoked.

Q: What is the difference between credential phishing and consent phishing?

A: Credential phishing steals passwords or session material, while consent phishing persuades a user to authorize a malicious application. The first attacks login, the second attacks delegated access. That distinction matters because the defensive controls are different: password hygiene helps one, but OAuth governance is needed for the other.

Q: When should organisations disable user OAuth consent?

A: Organisations should disable or tightly restrict user consent when apps can request sensitive data, tenant-wide access, or offline refresh tokens. If the environment has many SaaS integrations, admin approval is usually safer than broad self-service consent because it reduces the chance of hidden persistence.

Technical breakdown

OAuth consent abuse and bearer token persistence

OAuth 2.0 separates authentication from authorization. A user proves identity to the identity provider, then grants scopes to an application, which receives access and refresh tokens. In consent phishing, the attacker never needs the password or MFA challenge because the victim authorizes the malicious app directly. Those tokens are bearer credentials, so possession is enough to act. Refresh tokens make the problem durable because they can mint new access tokens long after the original session ends. That is why password resets often do not remove attacker access and why the control failure sits in token governance, not sign-in hardening.

Practical implication: Track app grants, token lifetimes, and refresh-token use as part of identity control monitoring.

Device-code phishing and first-party application abuse

Device-code phishing uses a legitimate OAuth flow built for devices with limited input, then redirects the victim to enter a code on a real provider page. ConsentFix and similar variants push this further by abusing first-party applications such as Azure CLI or PowerShell, which are often trusted more than ordinary third-party apps. The security problem is that the flow appears normal to the identity provider, endpoint tools, and the user. The attacker is not breaking MFA. They are exploiting trust in a sanctioned authorization path and, in some cases, in apps that are already broadly allowed inside the tenant.

Practical implication: Constrain device-code flows and explicitly review which first-party apps can request privileged scopes.

OAuth governance for SaaS integrations and NHI visibility

OAuth apps, service accounts, and API integrations are all non-human identities when they can act on behalf of users or systems. They often sit outside the controls used for human identity governance, which creates a visibility gap across SaaS-to-SaaS connections. Static inventories are not enough because malicious behavior can emerge after consent, during token use, or through unusual API patterns. That makes behavioral monitoring and consent policy enforcement core NHI controls, especially where third-party vendors, admin tools, and delegated access overlap. The right model is to treat every high-scope app as an identity with its own lifecycle.

Practical implication: Inventory every OAuth app and map each one to owner, scopes, lifecycle, and review cadence.

Threat narrative

Attacker objective: The attacker wants durable SaaS access through tokens that survive password changes and blend into normal application activity.

1. Entry occurs when a victim is tricked into granting OAuth consent to a malicious or compromised application through a real authorization screen.
2. Escalation follows when the attacker exchanges that consent for access and refresh tokens that can call SaaS APIs without re-authentication.
3. Impact is persistent access to mail, files, and connected SaaS data, often without triggering MFA or traditional credential-based alerts.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

OAuth consent is now an identity governance problem, not a phishing variant. The control failure happens after authentication, inside the authorization layer that most IAM programmes still treat as secondary. Once a user grants an app scopes, the attacker inherits the token lifecycle, not the login session. Practitioners should therefore manage app consent as a standing identity process, not a one-time security exception.

Bearer-token persistence creates an identity blast radius that password policy cannot contain. Password resets, MFA, and even passkeys do not revoke an already issued token. That shifts the security question from 'Did the user authenticate?' to 'What can this app do, for how long, and under whose approval?' Teams that do not answer those questions will keep overestimating their SaaS control coverage.

Device-code and first-party app abuse expose a runtime governance gap. The article's value is not that attackers found another phishing trick. It shows that sanctioned flows can become attacker transport when governance stops at login and ignores runtime behavior. That is a broader NHI lesson: any identity that can persist, refresh, or act across SaaS boundaries needs lifecycle controls, not just intake approvals.

Consent phishing will keep accelerating because it scales through legitimate infrastructure. Automated kits lower the skill bar while trusted cloud domains lower the detection bar. That combination makes the threat durable across environments with mature MFA but weak OAuth controls. Practitioners should assume the attack surface is growing faster than manual review processes can handle.

The operational standard has to move from approval to continuous accountability. High-risk OAuth apps need scoped ownership, periodic recertification, behavioral baselines, and immediate revocation paths. Without those controls, organizations will keep confusing administrative trust with security trust, and attackers will keep exploiting the difference.

From our research:

• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• From our research: 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• The right next step is to pair OAuth governance with the 52 NHI breaches Report so teams can connect token abuse patterns to real incident outcomes.

What this signals

Ephemeral consent debt: every approved OAuth grant creates a lifecycle obligation that outlives the login event. With 85% of organisations lacking full visibility into third-party vendors connected via OAuth apps, per The State of Non-Human Identity Security, the governance problem is already structural rather than exceptional.

NHI programmes should expect more attacks that look legitimate at the transport layer and malicious only at runtime. That means the control stack has to move toward behavioral detection, app recertification, and token revocation workflows that can be executed quickly when consent becomes suspicious.

Teams that already map service accounts and workload identities should extend the same lifecycle discipline to OAuth apps and delegated SaaS access. The practical signal is simple: if an identity can persist, refresh, or impersonate a user, it belongs inside the NHI governance model.

For practitioners

• Restrict user consent for high-risk scopes Require admin approval for permissions such as mail, file, directory, and offline access, and separate low-risk self-service grants from tenant-wide entitlements. Review the consent policy alongside privileged access rules, not as a standalone app setting.
• Inventory every OAuth app and its owner Create a register that ties each application to a business owner, granted scopes, refresh-token exposure, and review interval. Include first-party tools such as Azure CLI and PowerShell in the same inventory so they do not escape governance.
• Monitor token behavior, not just sign-ins Alert on unusual API volume, new redirect URIs, consent outside normal hours, and token use from unexpected IP space or user agents. Behavioral signals are the practical way to detect abuse after the authorization step.
• Revoke and recertify dormant app grants Build a monthly cleanup process for stale applications, unused refresh tokens, and high-scope grants that have not been exercised recently. Treat dormant consent as live exposure until it is removed.

Key takeaways

• Consent phishing bypasses MFA by abusing the OAuth authorization layer rather than stealing passwords.
• Bearer tokens and refresh tokens create durable access that survives routine credential resets.
• The practical defense is OAuth governance, behavioral monitoring, and rapid revocation of risky app grants.

Key terms

• Consent Phishing: A social engineering attack that persuades a user to approve a malicious OAuth application. The attacker gains delegated access through legitimate authorization rather than stealing a password, which makes the resulting token-based access harder to detect and revoke than a normal sign-in compromise.
• OAuth Access Token: A short-lived bearer credential issued after successful authorization that allows an application to call APIs on a user's behalf. In NHI governance terms, it is a reusable access artifact whose scope, expiry, and revocation path must be controlled like any other privileged credential.
• Refresh Token: A longer-lived credential that can mint new access tokens without forcing the user to authenticate again. Because refresh tokens can preserve access for extended periods, they are a major governance concern when malicious or over-scoped applications are granted consent.
• OAuth Consent Policy: A set of rules that determines which applications and permission scopes users may approve without review. Effective consent policy is an NHI control because it limits delegated access, reduces hidden persistence, and forces high-risk grants through administrative oversight.

Deepen your knowledge

OAuth consent governance and token lifecycle control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for SaaS integrations and delegated access, it is worth exploring.

This post draws on content published by Obsidian Security: Consent Phishing, how OAuth attacks bypass MFA and traditional security controls. Read the original.