What breaks when OAuth consent phishing bypasses MFA and passkeys?

Why This Matters for Security Teams

oauth consent phishing changes the defender’s problem from login security to delegated access security. MFA and passkeys can still be working exactly as designed while an attacker tricks a user into approving a malicious app or browser-based consent flow. That matters because the grant often creates durable access to mail, files, chats, or downstream APIs without ever stealing the primary password.

This is why modern identity guidance treats authorization and consent as first-class controls, not a footnote to authentication. NIST Cybersecurity Framework 2.0 frames identity protection inside broader access governance, but the operational lesson is sharper for SaaS and cloud apps: if consent is weak, the session boundary is already gone. The most visible failures typically appear in third-party app ecosystems, where scope creep and weak review processes make a legitimate approval look harmless until data starts moving out.

NHIMG research shows the scale of that visibility gap: The State of Non-Human Identity Security found that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps. In practice, many security teams encounter consent abuse only after mailbox forwarding, API extraction, or suspicious app activity has already started, rather than through intentional consent review.

How It Works in Practice

The attack chain usually starts with a convincing consent prompt, not a broken login. The user authenticates with MFA or a passkey, then authorizes an application that requests scopes far broader than the task requires. Once consent is granted, the app can receive tokens or ongoing delegated access that outlives the browser session and can be used from anywhere the token is valid.

That is why response should focus on token lifecycle, app trust, and scope control. Current guidance suggests treating OAuth applications as privileged integrations and reviewing them with the same discipline used for NHI governance, including NIST Cybersecurity Framework 2.0 style access controls and logging expectations. Operationally, teams should:

• restrict self-service consent where the platform allows tenant-wide enforcement
• require admin approval for high-risk scopes such as mail read, offline access, file write, or directory access
• inventory OAuth apps and continuously review granted scopes, owners, and last-used timestamps
• monitor for unusual token use, impossible travel, inbox rule creation, and lateral movement through connected services
• revoke consent and rotate any dependent secrets or refresh tokens after suspicious approval events

Real-world cases show why this matters. The Salesloft OAuth token breach demonstrated how stolen OAuth material can bypass the login ceremony entirely, while the Microsoft Midnight Blizzard breach highlighted the value of token theft and downstream access over interactive authentication. These controls tend to break down when organisations allow broad user consent in large SaaS estates because the app approval path is faster than governance review.

Common Variations and Edge Cases

Tighter consent controls often increase friction for legitimate business apps, requiring organisations to balance user productivity against the risk of over-broad delegation. That tradeoff is real, especially in environments with many low-code tools, partner integrations, or marketing and sales platforms that rely on OAuth by design.

There is no universal standard for every platform yet, so best practice is evolving. Some environments can block user consent entirely and route all requests through admin review. Others need a tiered model where low-risk scopes are auto-approved, while mail, files, and directory scopes trigger heightened scrutiny. In hybrid estates, the same app may be benign in one tenant and dangerous in another because tenant configuration, conditional access, and existing data exposure differ.

Two edge cases deserve attention. First, passkeys reduce credential replay but do not prevent approval of a malicious application inside a legitimate session. Second, consent phishing can be paired with NHI abuse when the attacker uses the granted token to access service mailboxes, automation accounts, or workflow APIs that were never intended for human-driven review. The Dropbox Sign breach is a useful reminder that delegated integrations can become a high-impact access path when governance lags behind application sprawl.

Related resources from NHI Mgmt Group

• What breaks when device code phishing is allowed in everyday enterprise workflows?
• What actions should I take if my OAuth tokens are compromised?
• How do attackers operationalise stolen OAuth tokens at scale?
• How should organizations respond to OAuth token abuse incidents?