OAuth consent phishing is bypassing MFA through trusted login flows

At a glance

What this is: OAuth consent phishing tricks users into granting malicious apps access through real Microsoft or Google login flows, creating persistent API access without credential theft.

Why it matters: IAM, IGA, and NHI teams need to treat OAuth consent as an access-control decision, because approval can outlive the login event and bypass MFA protections.

Context

OAuth consent phishing is an access abuse pattern, not a password theft problem. The attacker exploits a legitimate authorization flow to obtain tokens and API permissions, which means the identity event is approval of an app, not authentication of a user.

That distinction matters for identity governance because the risk sits in consent, token lifetime, and app scope. When users can authorize applications without strong oversight, security teams inherit long-lived API access that traditional phishing controls are not designed to catch.

Key questions

Q: What breaks when users are allowed to approve OAuth apps freely?

A: When users can approve OAuth applications without tight governance, a single click can create long-lived delegated access to mail, files, chat, and APIs. The failure is not sign-in protection but consent control. Security teams lose visibility into which apps were trusted, which scopes were granted, and how far the token can reach.

Q: Why do malicious OAuth apps still work even when organisations use MFA?

A: They work because the attack targets the authentication session, not just the password. In an attacker-in-the-middle flow, the victim enters credentials and approves MFA on a counterfeit page, while the attacker relays the session in real time and captures the token or cookie. That bypasses the protection MFA normally provides against password theft alone.

Q: What are the warning signs that OAuth consent is being abused?

A: Warning signs include unexpected app registrations, broad scopes that do not match user role, consent events from unmanaged devices, and access patterns that continue after the original user interaction. The key indicator is persistence through delegated permissions rather than a one-time login anomaly. Security teams should treat those signals as active access, not benign configuration noise.

Q: When should organisations block device code flow entirely?

A: Organisations should block it wherever the business does not depend on it, especially for users who do not need CLI sign-in. If the flow is still essential for specific teams, use report-only testing first, then enforce with narrow exceptions so you do not break legitimate developer access.

Technical breakdown

How malicious OAuth consent turns approval into API access

OAuth consent phishing works because the user authorises an application through a real identity provider flow. After approval, the application receives access and often refresh tokens, which lets it continue making API calls on the user’s behalf after the original session expires. This is not session hijacking in the classic sense. It is delegated access created by the user’s own approval, which makes the malicious app appear legitimate inside the tenant. Practical implication: consent boundaries must be treated as a security control surface, not a convenience feature.

Practical implication: Apply consent governance to limit which apps can receive delegated API access.

Why MFA does not reliably block OAuth phishing

MFA protects authentication, but OAuth consent abuse happens after a successful sign-in. The user may complete MFA on a trusted Microsoft or Google page and then approve a malicious application on the next screen. Once tokens are issued, the attacker no longer needs to replay credentials or satisfy another MFA challenge for every API action. This is why the attack can look clean in authentication logs while still producing persistent access. Practical implication: security teams must separate sign-in assurance from app-authorisation assurance.

Practical implication: Review MFA as one layer and add controls over app consent and token issuance.

Device code phishing reduces user scrutiny by changing the consent path

Device code phishing abuses the OAuth 2.0 Device Authorization Grant by moving the user to a real verification page and a short code entry step. That design is legitimate for constrained devices, but in phishing it shifts attention away from the app identity and requested scopes. The user sees a trusted domain and may focus on completing verification rather than checking the permissions being granted. The attacker then polls the token endpoint and receives access as soon as the code is approved. Practical implication: flows designed for usability need stricter organisational guardrails when they are exposed to general users.

Practical implication: Block or tightly restrict device code flow where it is not operationally required.

Threat narrative

Attacker objective: The attacker wants durable API-level access to user resources such as mail, files, and messages without stealing passwords.

1. Entry begins when the user receives a phishing message that routes them to a legitimate Microsoft or Google authentication flow.
2. Credential_harvested is not the main event here; instead the attacker harvests delegated access when the user approves the malicious application and token issuance begins.
3. Escalation occurs as the attacker uses the granted access and refresh tokens to make repeated API calls on the user’s behalf without further MFA prompts.
4. Impact is sustained mailbox, file, or message access that can persist until the consent grant or tokens are explicitly revoked.

Breaches seen in the wild

• Uber breach 2022: A contractor's stolen password and MFA fatigue gave a Lapsus$-linked attacker Uber's internal tools; Uber rotated keys to many services.

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

Consent is the real trust boundary: OAuth phishing succeeds because users are asked to authorise an application, not just prove who they are. That means the security decision moves from authentication to delegated access, and the programme has to govern app consent as a privileged action. The implication is that consent review, scope limitation, and app allowlisting are identity controls, not optional hygiene.

OAuth token persistence creates identity blast radius: Once a malicious application receives tokens, the attacker can continue operating without repeated user interaction. That makes revocation speed, token visibility, and app inventory far more important than a single successful MFA event. Practitioners should treat the duration of token validity as part of the exposure model, because the blast radius continues until access is actively removed.

Device code flow is a governance exception, not a default user path: The device authorization grant was built for constrained devices, but it becomes a social-engineering amplifier when exposed broadly. The control problem is not the protocol itself; it is allowing a low-context flow to be used where app identity and scope scrutiny are weakest. Practitioners should classify device code as a bounded exception and govern it accordingly.

Consent governance now sits alongside authentication governance: Traditional MFA-centric programmes can miss the fact that attackers are exploiting legitimate authorisation screens. The field needs to stop treating OAuth abuse as a phishing variant and start treating it as an access-governance failure with human, SaaS, and workload implications. The practical conclusion is that identity security teams must own app consent policy the same way they own privileged access policy.

New concept, delegated access debt: Each approved malicious or unnecessary OAuth grant adds persistent access that accumulates outside normal session controls. Over time, that creates a debt of unreviewed permissions, stale tokens, and app entitlements that are difficult to see in standard login telemetry. Practitioners should track delegated access as a lifecycle problem, not only an incident response problem.

From our research library:

• Security researchers tracked consent phishing campaigns affecting 900 tenants and 3,000 user accounts in 2025.

What this signals

Delegated access debt: OAuth abuse leaves behind approved apps and tokens that behave like standing access until revoked. That changes the governance problem from single-event phishing response to lifecycle management for app consent, token scope, and revocation hygiene.

Security teams should stop measuring OAuth risk only by login events. The more useful signal is whether app consent, scope approval, and token review are controlled with the same discipline as privileged account access.

For practitioners

• Limit user consent by default Require admin approval for new OAuth app grants, especially for scopes that can read mail, send messages, or access files.
• Restrict high-risk OAuth scopes Block unverified or look-alike applications and require publisher verification where it is available to reduce impersonation risk.
• Review and revoke stale tokens Continuously monitor enterprise app consent events and remove OAuth tokens that are unnecessary, unrecognised, or no longer justified.
• Treat device code flow as an exception Disable device code flow through Conditional Access unless a real business use case requires it, and document who can use it.
• Train users on consent as an access decision Teach users to scrutinise app names and permissions on real Microsoft or Google pages before they approve anything.

Key takeaways

• OAuth consent phishing exploits legitimate authorisation flows, so the security failure sits in delegated access rather than password compromise.
• MFA alone does not stop the attack because the user completes authentication before granting the malicious app persistent token-based access.
• The most effective controls are consent restriction, app verification, token review, and tighter governance over device code flow.

Key terms

• OAuth App Consent Phishing: A social engineering technique that tricks users into granting a malicious application access to their accounts or data. The app appears legitimate, but the consent flow is used to gain foothold, collect tokens, or redirect the victim into a credential capture page that can lead to account takeover.
• Device code phishing: An identity attack that abuses the device authorization flow by tricking a user into entering a code on a legitimate login page while the attacker completes the flow elsewhere. It is effective because it relies on a real authentication protocol and can bypass password theft and familiar MFA prompts.
• Delegated Access Token: A delegated access token is a short-lived credential issued for a specific task on behalf of an identity. In agentic environments, it limits what the runtime can do, where it can go, and how long the authority lasts, which is essential when access must be brokered rather than carried.
• Consent Governance: Consent governance is the set of policies, systems, and evidence needed to collect, record, propagate, and withdraw permission for data processing. It becomes operationally meaningful only when the organisation can prove that downstream systems honour the decision consistently across channels and vendors.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.