TL;DR: Push Security’s disclosure of ConsentFix shows how attackers can turn a legitimate Microsoft Entra ID OAuth consent flow into account takeover without stealing passwords or MFA codes, SecureAuth says, because users can be coerced into handing over redeemable authorization material. The real problem is that identity controls often protect authentication while leaving portable authority and consent governance weak.
At a glance
What this is: This is a disclosure of ConsentFix, a browser-native OAuth consent abuse technique that turns a legitimate Microsoft Entra ID flow into account takeover without stealing passwords or MFA codes.
Why it matters: It matters because IAM teams often harden authentication while leaving consent, scope grants, and portable authority under-governed, which creates takeover paths that bypass the controls many programmes still treat as primary.
Context
ConsentFix is a social-engineering attack against OAuth consent flows, not a password theft campaign. The attacker manipulates a user into completing a real authorization step, then redeems the resulting authorization material for access and refresh tokens.
The governance gap is broader than Microsoft Entra ID alone: identities are often protected at sign-in, while delegated authority is still granted too easily at consent time. That makes OAuth approval, app trust, and scope governance part of identity security, not a side concern.
For IAM and NHI practitioners, the lesson is that a valid login journey can still produce malicious access when the policy boundary sits too far downstream from authentication.
Key questions
Q: What breaks when OAuth consent is treated like a one-time setup step?
A: Consent turns into standing delegated access when teams stop tracking scopes, owners, and tenant-specific service principals after approval. The result is access that outlives the business need and becomes difficult to review, revoke, or explain during governance checks.
Q: Why do strong MFA and passkeys still fail against OAuth consent abuse?
A: Because MFA and passkeys validate the user at sign-in, but they do not automatically control what the user can delegate to an application after authentication succeeds. If consent policy is permissive, a trusted login can still produce untrusted portable authority. The control gap sits at grant time, not at the password prompt.
Q: How do security teams know consent governance is actually working?
A: They should look for evidence that banner choices, tag behaviour, and audit records all align across every relevant flow. A working programme shows the denied path is enforced, the granted path is consistent, and changes are controlled rather than improvised at the tag level.
Q: Should organisations prioritise consent controls or more user training first?
A: Consent controls should come first when the abuse path depends on valid workflow abuse rather than obvious fake-login phishing. Training helps, but it is not reliable against browser-native coercion that uses real Microsoft pages. Policy-based scope restriction and contextual approval are the faster risk reducer.
Technical breakdown
How OAuth consent abuse turns a real login into token issuance
OAuth is designed to let a user or administrator grant an application scoped access without sharing credentials. In ConsentFix, the attacker does not need to break authentication; they need the victim to complete a legitimate consent journey so the platform issues redeemable authorization material. Once that material is exchanged, the attacker receives access and refresh tokens that behave like portable authority. The security boundary therefore shifts from password theft to delegation abuse, which is why traditional credential hygiene does not stop this class of attack.
Practical implication: treat consent and scope issuance as an access-control boundary, not a user-experience detail.
Why MFA and passkeys do not stop delegated authority abuse
MFA and passkeys verify the user at sign-in, but they do not automatically govern what the user can delegate to an application after authentication succeeds. That is the key failure mode here. A user can pass strong authentication and still authorise an untrusted or malicious client if the consent experience is open-ended or poorly constrained. Once tokens exist, the attacker can act programmatically across Microsoft 365 and Azure with the user’s authority, even though no password was stolen and no MFA challenge was bypassed.
Practical implication: separate authentication strength from consent authorisation strength in your control design.
Browser-native coercion and why user training is not enough
ConsentFix blends ClickFix-style prompting with a real Microsoft flow, which makes the lure harder to spot than classic fake-login phishing. Because the page can arrive through compromised sites or malvertising, the user may be pushed to copy and paste or complete steps inside a legitimate-looking browser context. That reduces the value of awareness messages focused only on suspicious passwords or fake login pages. The real issue is that the workflow itself can be abused when the application and scope are permitted to cross the trust boundary.
Practical implication: reduce reliance on user recognition and enforce policy at the consent boundary itself.
Threat narrative
Attacker objective: The attacker aims to obtain token-based user authority that enables account takeover and downstream access to Microsoft 365 and Azure resources.
- Entry begins when the victim reaches a lure page delivered through compromised sites or malvertising and is pushed into a real Microsoft Entra ID authorization journey.
- Credential harvesting occurs when the user is coerced into providing redeemable authorization material, such as an OAuth authorization code, rather than a password or MFA code.
- Escalation follows when the attacker redeems that material for access and refresh tokens, then uses them to operate as the user across Microsoft 365 and Azure.
- Impact is account takeover with programmatic access that bypasses the protections many teams assume are covered once authentication succeeds.
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.
- Microsoft Midnight Blizzard breach: Midnight Blizzard (APT29) exploited legacy test account without MFA to breach Microsoft.
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 governance has become an access-control problem, not just an application-consent problem: ConsentFix works because the security boundary is placed too far after authentication. The user can pass MFA and still hand over durable authority through a legitimate OAuth grant. That means IAM teams must treat delegated consent as a governed entitlement path, not as a secondary event after login.
Portable authority is the real asset in this attack: The attacker is not trying to steal a reusable password, they are trying to convert a user action into tokens that travel across services. That is a different governance model from session-only authentication because token issuance extends identity reach beyond the moment of sign-in. Practitioners should recognise that consented scope is a privilege decision with blast-radius implications.
Continuous verification cannot stop what policy already allowed to be delegated: Secure sign-in controls do not prevent an unsafe client from receiving authority in the first place. The weak point is the policy around who can grant what, under which device, risk, and application conditions. The implication is that consent-time controls now sit alongside MFA as a first-line governance control.
Browser-native social engineering is collapsing the line between phishing and authorization abuse: ConsentFix shows that user coercion no longer needs a fake credential prompt to succeed. If the workflow is legitimate and the grant is permitted, the attacker can exploit the trust path itself. That pushes identity teams toward stronger scope governance and tighter client approval logic, because the old distinction between phishing and authorization abuse is no longer operationally reliable.
Identity programmes need a named concept for this failure mode: consent-to-authority drift: The article illustrates how an apparently small user consent action can expand into broad delegated access across cloud services. That drift happens when authentication assurance is treated as the main control while scope approval remains permissive. The practitioner takeaway is to govern how authority is minted, not only how users are verified.
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
Consent-to-authority drift: IAM programmes are still optimising sign-in assurance while attackers increasingly exploit the delegated-authority layer. The practical shift is to evaluate whether scope grants, app trust, and consent approval are governed as access decisions with the same rigour as privileged logins.
The next control question is not whether the user authenticated strongly enough. It is whether the application should have been allowed to receive that scope from that user in that context at all.
For practitioners
- Tighten OAuth consent policies Restrict which clients can receive sensitive scopes, and require explicit approval for high-risk permissions rather than letting any app request them.
- Gate scope grants by device and context Allow delegated access only from managed devices, expected networks, normal geographies, and acceptable risk states so consent is not a standing privilege path.
- Separate admin and workforce consent paths Use different consent rules for privileged users and general workforce users, especially where app scopes can expose mail, files, or directory data.
- Review token-issuing apps and consented scopes Inventory applications that already hold powerful Microsoft Entra ID permissions and revoke any untrusted or no-longer-needed grants.
- Train users on consent coercion, not just fake logins Update awareness content so staff recognise browser-native prompts that ask them to complete a legitimate flow for an unknown or unexpected application.
Key takeaways
- OAuth consent abuse can turn a legitimate Microsoft Entra ID flow into account takeover without password theft or MFA bypass.
- The core weakness is not authentication strength but the governance of delegated authority, client trust, and scope issuance.
- Security teams need to move controls closer to consent time so authority cannot be minted by a user action alone.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article shows that strong sign-in can be bypassed when consent is abused to mint tokens. |
| NHI-10 — Human Use of NHI | A human is coerced into using OAuth authority in a way that benefits the attacker. | |
| Recommendation — Treat consent-time token issuance as an authentication boundary and deny unsafe grants by default. Restrict human-initiated grants that expose machine-consumable authority to untrusted apps. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Token and authenticator lifecycle controls are central because the attack redeems authorization material into access tokens. |
| Recommendation — Apply IA-5 to govern token issuance, lifecycle, and revocation for OAuth-based access paths. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Consent abuse is fundamentally a failure to govern permissions and entitlements at grant time. |
| Recommendation — Enforce PR.AA-05 so application entitlements are approved, bounded, and reviewed before issuance. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The technique converts user interaction into token access and then broad internal movement. |
| Recommendation — Map OAuth consent abuse to TA0006 and TA0008 to hunt for token redemption and post-consent access expansion. | ||
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.
- Portable Authority: Portable authority is access that can be carried and used programmatically after a user or application receives a token. It is different from a one-time login because the resulting token can operate across services until it expires or is revoked.
- 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.
- Delegated Scope: Delegated scope is the set of actions and resources a receiving agent is allowed to use on behalf of the originating actor. Effective scope should be narrower than the agent's raw capability and must be checked at every handoff, not just at session start.
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.
Published by the NHIMG editorial team on September 2, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org