ConsentFix shows OAuth consent abuse bypasses passwords and MFA

At a glance

What this is: ConsentFix is a browser-native phishing technique that abuses Microsoft Entra ID OAuth consent flows to obtain redeemable authorization material and exchange it for tokens.

Why it matters: It matters because IAM teams must govern consent, token issuance, and app scope, not just passwords and MFA, across human identity and NHI-style token use cases.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes , and as quickly as 9 minutes in some cases.

👉 Read SecureAuth's analysis of browser-native OAuth consent abuse and ConsentFix

Context

OAuth consent abuse is a governance problem, not just a phishing problem. When a user can be manipulated into approving a real authorization flow, the attacker bypasses password theft and moves straight to portable access.

ConsentFix is especially relevant to IAM programmes because it targets the boundary between authentication and delegated authority. That boundary is where many organisations still assume user awareness, MFA, or email filtering will stop abuse, even when the actual risk sits in consent policy and token redemption.

For enterprises running Microsoft Entra ID, the practical issue is that legitimate Microsoft pages can be used as the delivery mechanism for malicious consent. That makes app governance, scope restriction, and contextual policy enforcement central rather than optional.

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: Why do OAuth consent attacks create account takeover risk even with MFA?

A: MFA protects the authentication step, but OAuth consent abuse targets the authorization step. If the user is tricked into approving a legitimate flow, the attacker can redeem authorization material into tokens and act programmatically as the user. The risk is not bypassing the login challenge, but hijacking the delegated authority that follows it.

Q: How should security teams reduce the impact of malicious OAuth consent grants?

A: They should restrict which apps and users can complete high-risk consent paths, remove unnecessary Conditional Access exclusions, and review token reuse across app families. The goal is to shrink the blast radius of any single browser interaction so that one successful consent does not become broad platform access.

Q: What is the difference between authentication strength and consent governance?

A: Authentication strength proves the user or session is credible at login, while consent governance controls what delegated access can be created afterward. Strong MFA can still coexist with malicious scope grants if users are allowed to approve risky apps. IAM teams need both controls because they defend different parts of the trust chain.

Technical breakdown

How OAuth consent abuse turns login into delegated authority

OAuth consent flows are designed to let a user approve an application to access resources on their behalf. In a ConsentFix-style attack, the attacker does not need the password or MFA response; they need the user to complete a genuine authorization journey and hand over an authorization code or similar redeemable material. That code can be exchanged for access and refresh tokens, which then operate as delegated authority across Microsoft 365 and Azure. The abuse works because the trust decision happens at consent time, not at password collection time.

Practical implication: govern who can consent to which scopes, not just how users authenticate.

Why browser-native lures are harder to block than classic phishing

Browser-native social engineering blends malicious prompts with legitimate web sessions, often delivered through compromised sites, ads, or other trusted-looking paths. Because the user is interacting with a real Microsoft flow, traditional controls that look only for fake login pages or credential entry are less effective. The attacker is exploiting user behaviour inside the browser session and then converting that session interaction into persistent authority. That shifts detection requirements toward application consent governance, abnormal authorization requests, and token redemption monitoring.

Practical implication: add consent-time controls and browser-session telemetry to your detection model.

Continuous authority is the control gap ConsentFix exposes

The technique highlights a common identity assumption: if authentication succeeded, the resulting delegated access is trustworthy until revoked. ConsentFix breaks that assumption by showing that a legitimate-looking grant can still be malicious if the context, app, or requested scope is unsafe. Continuous authority models respond by re-evaluating access based on runtime context instead of treating consent as a one-time event. In practice, that means consent decisions and token use must remain subject to policy after the initial grant.

Practical implication: treat consent as a governed event with ongoing policy checks, not a permanent trust decision.

Threat narrative

Attacker objective: The attacker wants durable delegated access that can be used programmatically to read data, act as the user, and extend access across Microsoft 365 and Azure.

1. Entry occurs when the victim reaches a lure page delivered through compromised sites, malvertising, or another browser-native path that initiates a real Microsoft consent journey.
2. Escalation occurs when the user is coerced into copying or approving authorization material that the attacker can redeem for access and refresh tokens.
3. Impact occurs when the attacker operates programmatically as the user across Microsoft 365 and Azure, bypassing password and MFA theft entirely.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• CoPhish OAuth Token Theft via Copilot Studio — CoPhish campaign exploits Microsoft Copilot Studio agents to steal OAuth tokens via AI-assisted phishing.

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

NHI Mgmt Group analysis

ConsentFix exposes a delegated-authority problem, not a credential problem. The attacker does not need to defeat password controls when the real weakness is user-granted permission that can be redeemed into token-based access. That means IAM teams must treat OAuth consent as a privileged control surface, not a convenience feature.

Portable authority is the more dangerous asset in modern identity attacks. Once authorization material is redeemed, the attacker can move through Microsoft 365 and Azure as the user without re-entering the authentication path. The governance lesson is that access risk increasingly lives in the lifecycle of the token, scope, and app registration rather than the login event itself.

Consent policy is now part of enterprise access governance. Organisations that leave broad user consent enabled are effectively allowing low-friction delegation into production systems. The practical conclusion is that consent boundaries need the same scrutiny traditionally reserved for privileged access.

Browser-native social engineering collapses the old distinction between phishing and application abuse. The user still interacts with a real vendor page, but the attacker controls the intent behind the request. For identity programmes, that means detecting malicious prompts is no longer enough; the control point has moved to app trust, scope restriction, and contextual approval logic.

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.
• That visibility gap matters because OAuth consent abuse often rides through legitimate integrations that security teams do not fully inventory or review.
• For a broader governance lens, see Top 10 NHI Issues for the control patterns that consistently fail when delegated access is left unmanaged.

What this signals

Consent governance is becoming part of the identity perimeter. As more access is granted through apps, tokens, and delegated scopes, IAM teams need visibility into which integrations can create portable authority. The practical signal is that app approval workflows now deserve the same governance discipline as privileged access requests.

OAuth abuse creates an NHI-style control problem inside human identity journeys. The user still looks like the subject of the interaction, but the durable asset is the token or consent grant. That means identity programmes should inventory consented applications, not just user accounts, because delegated access can outlive the session that created it.

1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months. That investment trend reflects a broader shift: access governance is moving from static authentication checks toward lifecycle control over tokens, scopes, and non-human permissions.

For practitioners

• Restrict user consent to approved apps and scopes Block broad end-user consent where possible, and allow only pre-approved applications to request sensitive scopes. Separate general workforce permissions from administrative or high-risk consent paths.
• Require contextual approval for risky OAuth grants Gate sensitive consent decisions on managed device status, normal geography, expected network, and low-risk posture. Deny or step up when the request comes from an unknown app or unusual context.
• Monitor token issuance and abnormal app consent patterns Alert on spikes in authorization-code redemption, unusual app registrations, and consent grants to new or untrusted clients. Review any grant that produces access to Microsoft 365 or Azure outside expected onboarding flows.
• Tighten the boundary between authentication and delegated access Review where MFA is treated as a sufficient control and replace that assumption with consent-time policy, app trust checks, and post-grant monitoring. Authentication strength does not neutralise malicious delegation.

Key takeaways

• ConsentFix demonstrates that attackers can hijack delegated authority without stealing passwords or MFA codes.
• The main failure mode is weak OAuth consent governance, especially when users can approve powerful app scopes without contextual controls.
• IAM teams should treat token issuance, app trust, and consent policy as first-class security controls, not post-authentication conveniences.

Key terms

• OAuth Consent: The approval that allows an application to access resources on behalf of a user or tenant. In practice, consent can create durable access paths that outlive the original interaction if permissions are broad, unmanaged, or never reviewed. For security teams, it is both an access decision and a lifecycle event.
• Delegated Agent Authority: The permission granted to an AI agent to act on behalf of a human user or another agent, inheriting some or all of their access rights. Delegated authority must be explicitly scoped, time-limited, and auditable.
• Continuous Authority: Continuous authority is a governance model that re-evaluates access using live context instead of trusting a one-time grant forever. It is especially relevant when tokens, consents, and app scopes can be abused after authentication, because it keeps the decision boundary active across the session.
• Consent-Time Policy: Consent-time policy is the set of rules that determine whether an application may receive a requested OAuth grant. It matters because the security decision happens at approval time, where scope, app trust, user role, device posture, and risk context can all be enforced.

What's in the full article

SecureAuth's full analysis covers the operational detail this post intentionally leaves for the source:

• Browser-native attack flow details showing how the lure, consent step, and token redemption chain work in practice
• Policy-based continuous authority controls for blocking risky consent grants at runtime
• Developer subscription and scope-gating logic for preventing unknown apps from attaching to powerful permissions
• Operational examples of contextual checks that can hard-deny suspicious OAuth consent requests

👉 SecureAuth's full post covers the ConsentFix flow, scope governance controls, and continuous authority model

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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.