Consent phishing bypasses MFA by abusing OAuth trust in SaaS

At a glance

What this is: Consent phishing is a browser-based OAuth attack that bypasses MFA by tricking users into granting malicious applications access tokens that persist beyond password resets.

Why it matters: It matters because SaaS defenders who focus only on authentication miss the authorization layer, where trusted integrations can create durable access paths that traditional controls do not see.

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.

Context

OAuth consent attacks target the authorization layer, not the login screen. In this model, a user completes a legitimate sign-in and then grants a malicious app permission to act on their SaaS data, which means MFA can be working exactly as designed while the attacker still receives a durable token.

For IAM and SaaS security teams, the core governance problem is not password compromise but delegated trust. Once an OAuth token is issued, it can behave like a bearer credential inside connected applications, so the real exposure often sits in app consent, token scope, and third-party integration oversight rather than at the primary identity boundary.

Key questions

Q: What breaks when users can grant OAuth consent to risky applications?

A: The control that breaks is the assumption that a valid login equals safe delegated access. If users can approve powerful scopes for unknown or untrusted apps, attackers can convert a real consent flow into token-based access without stealing passwords or MFA codes. That makes consent policy a core access control, not a minor usability setting.

Q: What are the signs that consent phishing is being used to bypass MFA in a SaaS environment?

A: A common sign is an OAuth app suddenly requesting broad mailbox, file, or calendar permissions that do not match the user’s role or normal workflow. You may also see unusual app consent events, unexpected third-party integrations, or permissions granted shortly after a phishing email. Treat rapid permission grants and unfamiliar application names as possible account compromise indicators.

Q: How do teams know whether OAuth token governance is actually working?

A: Look for short token lifetimes, tested revocation, no tokens in logs, and a clean mapping from each integration to an accountable owner. If disconnected apps still retain access, or if nobody can explain which scopes are approved, the programme is functioning on paper only.

Q: What should teams do immediately after discovering a malicious OAuth grant?

A: Revoke the app grant, invalidate refresh tokens, terminate active sessions, and review any mailbox or API actions already taken through the compromised scopes. If the app was backdoored into a workflow, remove the malicious integration and confirm no additional delegated access remains.

Technical breakdown

How OAuth consent becomes a durable access path

OAuth 2.0 is designed to let applications access user data without sharing passwords. In a consent phishing attack, the victim authenticates to the real identity provider, then approves requested scopes for a malicious application. The application receives an authorization code, exchanges it for access and refresh tokens, and then uses those tokens directly against SaaS APIs. Because the token is the credential, not the password, the attacker keeps operating after the original sign-in completes.

Practical implication: Treat OAuth consent as an access-control event, not just a user-experience step, and govern which scopes can be issued at all.

Why MFA does not interrupt token abuse

MFA protects the authentication ceremony, but consent phishing happens after that ceremony succeeds. The user enters the legitimate login flow, completes MFA on the real domain, and then approves access for an attacker-controlled app. Once the token exists, the attacker no longer needs the password, the MFA challenge, or the victim session. This is why passkeys, phishing-resistant authenticators, and SSO hardening do not by themselves close the gap.

Practical implication: Separate authentication strength from authorization governance so teams do not mistake strong login controls for complete SaaS protection.

Why first-party apps and device-code flows matter

Attackers favour trusted or pre-consented applications, including first-party tools and device-code flows, because they blend into normal administrative activity. Device-code phishing shifts the trust decision to a legitimate activation page, while first-party app abuse exploits broad trust and policy exceptions that many environments grant to vendor tools. The result is a hidden layer of SaaS-to-SaaS trust that looks legitimate to static inventories but behaves like an attacker foothold once tokens are issued.

Practical implication: Review high-trust app paths, especially device-code and first-party OAuth grants, as privileged access paths rather than routine application traffic.

Threat narrative

Attacker objective: The attacker wants durable, low-friction access to SaaS data and adjacent applications without relying on stolen passwords or repeated MFA bypass.

1. Entry occurs when the victim is lured into a legitimate OAuth or device-code flow and completes sign-in on the real identity provider page.
2. Credential access occurs when the malicious application receives access tokens and refresh tokens through the consented authorization grant.
3. Escalation occurs when the attacker uses those tokens to call SaaS APIs, access mail or files, and create follow-on persistence such as inbox rules or additional app grants.
4. Impact occurs when the attacker maintains access after password resets and uses the trusted token path to expand into connected SaaS applications.

Breaches seen in the wild

• Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Authorization governance is the control plane consent phishing actually attacks. MFA strengthens identity proof at login, but it does not govern what an already authenticated user can delegate to a third-party app. That means app consent, scope approval, and token lifecycle are the decisive controls in SaaS, not just authentication depth. Practitioners should treat delegated authorization as a first-class governance surface.

Consent phishing creates a hidden trust layer that most SaaS inventories do not model. Static application lists show what is connected, but they do not show when a token becomes an operational foothold or when a benign integration turns into a persistence mechanism. This is where behavioural visibility matters more than one-time review. Practitioners need to govern token behaviour, not just app registration.

OAuth trust sprawl is a form of identity blast radius. Each pre-consented app, device-code exception, or broad admin grant enlarges the number of places where one compromised session can propagate. The issue is not only malicious apps, but the breadth of trust that normal SaaS convenience creates. Practitioners should measure blast radius in scopes, tokens, and downstream integrations.

Consent phishing shows that authentication-centric security models are incomplete for SaaS. The attack works because the industry still treats sign-in success as the end of identity assurance, when in SaaS it is only the start of delegated access. That assumption is now obsolete for teams governing cloud collaboration stacks. Practitioners need policy, telemetry, and offboarding controls that follow the token, not the password.

Obsidian Security's 2025 campaign data reinforces that consent abuse is already at scale. The combination of 900 affected tenants, 3,000 user accounts, and 17,000 malicious apps shows that this is not a niche edge case. The pattern is industrial enough to demand governance, detection, and user-education changes together. Practitioners should respond as though OAuth trust abuse is a standing SaaS risk.

From our research library:

• Across one million observed logins, 1 in 4 were password-based rather than SSO, 2 in 5 were not protected by MFA and 1 in 5 used a weak, breached or reused password.

What this signals

OAuth trust sprawl is now an identity governance problem, not just a phishing problem. SaaS environments accumulate delegated access that can remain valid long after the original sign-in event, so security programmes need controls for app consent, scope review, and token revocation. The practical shift is from protecting the login to governing the delegation path.

Consent phishing exposes the gap between authentication and authorization in cloud collaboration stacks. Organisations that measure identity risk only through MFA coverage will miss the hidden layer where trusted apps, device-code flows, and refresh tokens keep access alive. Practitioners should align their SaaS control model to the token lifecycle and the integrations that depend on it.

For practitioners

• Restrict user consent for high-risk OAuth scopes Require administrator approval for permissions such as Mail.Read, Files.ReadWrite.All, and Directory.Read.All, and review any scope that grants broad mailbox or file access.
• Monitor token behaviour continuously Alert on unusual API call volumes, suspicious user agents, anomalous IP addresses, and apps that access data outside their stated purpose.
• Limit trust in first-party and device-code flows Apply Conditional Access, device compliance, and role scoping to administrative tools such as Azure CLI and PowerShell, then reassess any default exemptions.
• Review app consent sprawl on a fixed cadence Inventory all consented apps, map their permissions to actual business need, and remove stale grants that no longer have a clear owner.

Key takeaways

• Consent phishing works because OAuth tokens can outlive the authentication event that created them, leaving a durable access path inside SaaS.
• The article reports campaigns affecting 900 tenants and 3,000 user accounts, which shows the pattern is already operating at meaningful scale.
• Teams that want to reduce exposure need governance over consent, scope, and token revocation rather than relying on MFA strength alone.

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.
• Delegated Authorization: A model in which an application is allowed to act on a user’s behalf after explicit approval. In SaaS environments, delegated authorization is powerful but risky because excessive scope or weak revocation can turn a routine integration into durable non-human access.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.