ConsentFix shows how OAuth phishing bypasses browser identity controls

At a glance

What this is: ConsentFix is a browser-native OAuth phishing technique that can turn a copied Microsoft URL into account takeover and API access without traditional login friction.

Why it matters: It matters because IAM teams cannot treat browser-based OAuth consent as a post-login afterthought when MFA, passkeys, endpoint checks, and some Conditional Access paths can be sidestepped.

Context

ConsentFix is a browser-native OAuth consent phishing technique that weaponises the user’s own signed-in browser session to obtain Microsoft account access. The key governance gap is that many identity controls assume the dangerous step is credential entry, when in this pattern the user is manipulated into authorising access through a legitimate flow already in progress.

The attack matters to identity teams because it shifts abuse from password theft to token and consent abuse. That means the relevant control boundary is not just authentication success, but what the browser, the OAuth flow, and the targeted app allow after sign-in.

Push Security’s analysis frames this as a post-authentication problem rather than a classic phishing problem. That distinction matters because browser-native token abuse changes where detection, policy enforcement, and user education need to operate.

Key questions

Q: What breaks when OAuth consent phishing happens inside the browser instead of at login?

A: Browser-native OAuth phishing breaks the assumption that authentication controls protect the whole identity transaction. The user may pass MFA or use passkeys, yet the attacker still wins by stealing the authorization code after login and redeeming it elsewhere. That shifts defence toward browser inspection, consent governance, and token-handling visibility, not just stronger sign-in methods.

Q: Why can OAuth-based phishing bypass MFA and passkeys in Microsoft environments?

A: Because those controls protect sign-in, not every post-authentication authorisation path. If the attacker captures or induces a valid OAuth grant, the identity provider may issue tokens after the user has already passed MFA. That is why consent and targeted app policy matter as much as the login ceremony.

Q: How do security teams know if OAuth abuse is slipping past detection?

A: The warning signs are gaps between user activity and identity telemetry. If sign-in logs look normal but browser behaviour shows unusual copy-paste, redirect, or code transfer patterns, the attack may already be in progress. Monitoring must include browser events, deprecated identity logs, and the specific application and resource IDs associated with suspicious consent activity.

Q: Should organisations block all OAuth device and consent flows to stop phishing?

A: Not automatically. The better decision is to narrow which applications can be consented to, restrict high-risk client IDs, and review where legitimate browser-based authorisation is actually required. Blanket blocking can disrupt business workflows, but ungoverned consent paths leave a large abuse surface.

Technical breakdown

How OAuth consent phishing turns browser trust into token issuance

OAuth consent phishing abuses the authorization grant process rather than stealing a password. In this case, the victim is coaxed into interacting with a legitimate Microsoft URL and sharing an OAuth authorization code or consent action that the attacker can exchange for tokens. Because the browser session is already authenticated, the user often sees little friction. The important technical point is that the attacker is not breaking authentication in the usual sense. They are using a valid identity transaction to mint access through a channel the victim believes is routine.

Practical implication: govern consent and token issuance as an attack surface, not just interactive login.

Why browser-native attacks can bypass MFA, passkeys, and Conditional Access

MFA and passkeys protect the login ceremony, but they do not automatically control every post-authentication authorisation path. ConsentFix exploits that boundary by operating after sign-in and, in some cases, by targeting application IDs with known Conditional Access exclusions. The result is that the attacker can obtain API-level access without re-entering credentials or re-performing MFA. This is why browser-native attacks are structurally different from password phishing: the identity system may correctly authenticate the user while still issuing dangerous access.

Practical implication: review which apps and auth flows remain reachable after primary authentication succeeds.

FOCI, refresh tokens, and why one granted token can widen exposure

The article notes that attackers can pivot from one OAuth grant to broader access through app scopes, refresh tokens, and FOCI behaviour. FOCI, or Family of Client IDs, can let a token obtained for one Microsoft application be exchanged for access tokens to other related apps without new user interaction. That means the real blast radius depends on the target app, the granted scopes, and the user’s privileges, not just the initial phishing page. Token scope is therefore the control plane that determines how far the compromise can extend.

Practical implication: inventory high-utility OAuth apps and constrain who can authorise them.

Threat narrative

Attacker objective: The attacker wants durable account and API access that survives normal login protections and enables follow-on access to Microsoft services and data.

1. Entry begins when the victim is socially engineered into interacting with a phishing page that captures a legitimate Microsoft URL or OAuth material. The browser session makes the first step look routine rather than suspicious.
2. Credential and token abuse occurs when the attacker exchanges the captured OAuth code for session or refresh tokens tied to the victim’s account and targeted app.
3. Escalation follows when the attacker pivots through app scopes, FOCI behaviour, or privileged target applications to expand API reach across Microsoft services.
4. Impact is account takeover with API access to Outlook, Teams, OneDrive, SharePoint, or broader Entra-connected services, often without triggering the controls the user expected to protect sign-in.

Breaches seen in the wild

• Microsoft verified publisher OAuth phishing 2022: Malicious OAuth apps with a fraudulently obtained Microsoft verified publisher badge tricked UK users into granting mailbox access in 2022.
• Cyberhaven Chrome extension breach 2024: A phished OAuth consent gave attackers Chrome Web Store publishing rights and a malicious Cyberhaven extension update reached about 400,000 users.

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

ConsentFix exposes a browser-native trust boundary that most identity programmes still do not govern. Traditional IAM controls assume the risky event happens at credential entry or device enforcement. This technique shows that an authenticated browser session can be manipulated into issuing tokens that are far more powerful than the initial login event suggests. The practitioner conclusion is that browser-mediated authorisation must be treated as a first-class identity control surface.

Interactive login is no longer the right mental model for OAuth risk. The attack works because the user is not necessarily failing MFA or passkeys; the user is completing a valid authorisation flow under attacker influence. That means the security assumption being broken is not just weak authentication, but that human judgement at the point of consent is reliable enough to govern access scope. Teams need to rethink consent as an access decision, not a convenience step.

ConsentFix creates an identity blast radius problem, not just a phishing problem. Once a refresh token or related access token is minted, the scope of compromise depends on app permissions, client families, and downstream service reach. That makes token scope the meaningful unit of governance, because one successful consent event can extend into multiple Microsoft services without new user friction.

Browser-level detection becomes part of identity governance for post-authentication attacks. The article’s emphasis on DOM-level inspection and real-time blocking reflects a wider shift in control design. If the attack is executed entirely in the browser, then endpoint-only and inbox-only assumptions miss the abuse path. The practitioner implication is that identity, browser, and threat controls now have to operate as a combined enforcement layer.

OAuth consent governance should be judged by what remains reachable after the user is signed in. The article shows that targeting specific app IDs, exclusions, and first-party applications can narrow or widen abuse paths. The field should therefore move from generic “OAuth risk” language to explicit governance of consented application inventory, privilege boundaries, and post-authentication access paths.

From our research library:

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

What this signals

Consent phishing now sits inside the browser trust model rather than outside it. That changes the governance question from “did the user authenticate?” to “what could that signed-in browser session still authorise on behalf of the user?” Teams that do not monitor post-authentication token issuance will miss the most important part of the attack.

Identity teams should treat OAuth app inventory as a control surface, not a catalogue. The practical risk comes from which applications can be consented to, which scopes they request, and which users can authorise them without additional guardrails. Narrowing that surface is more useful than assuming all phishing resistance lives at the login layer.

ConsentFix also shows why browser telemetry belongs in identity operations. If the attack can be completed without touching the endpoint in the usual sense, then web-session analysis, real-time blocking, and token-context correlation become part of identity defence rather than adjacent tooling. The boundary between browser security and IAM is now operational, not theoretical.

For practitioners

• Audit OAuth consent paths for browser-native abuse Identify which apps can be authorised from a signed-in browser session without additional verification, then classify them by business criticality and privilege reach.
• Restrict high-risk application IDs and exclusions Review first-party and other high-utility applications that have conditional access exclusions, then limit which users can consent to them.
• Monitor token exchange and consent telemetry Correlate initial access IP, subsequent activity, and application IDs so a user-driven sign-in followed by attacker-driven actions stands out in logs.
• Treat the browser as an enforcement surface Use in-browser inspection and blocking for pages that mimic device code or consent phishing flows, because the abuse happens before endpoint controls can intervene.
• Constrain refresh-token blast radius Limit who can authorise apps with broad scopes and reduce the number of clients that can be silently reused through FOCI-style behaviour.

Key takeaways

• ConsentFix shows that browser-native OAuth abuse can turn a legitimate Microsoft session into account takeover without relying on password theft.
• The technique can bypass MFA, passkeys, and some Conditional Access paths because the abuse happens after the user has already signed in.
• The most effective control point is consent governance, application restriction, and browser-aware detection across token issuance and post-authentication activity.

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.
• Authorization Code Grant: An OAuth flow that lets an application receive user-approved access without collecting the user’s password. The browser handles consent and redirection, while the backend exchanges a short-lived code for tokens. For identity teams, the control question is whether the exchange is bound tightly enough to the original request.
• 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.
• Conditional Access: Conditional access is a policy model that decides whether an action should proceed based on context such as posture, resource sensitivity, timing, and scope. For AI agents, it must be evaluated at request time so a valid credential does not automatically equal permitted behaviour.

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.