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.
Why This Matters for Security Teams
Malicious OAuth apps succeed because MFA is not a complete defence once the attack shifts from password theft to consent abuse, token theft, or session hijacking. The user may still complete MFA, yet the attacker receives an access token that looks legitimate to downstream SaaS, API, and collaboration platforms. That is why organisations that trust login success as proof of safety often miss the real control point: app consent, token scope, and post-authentication access.
This is not a theoretical edge case. NHIMG research on the Salesloft OAuth token breach and the Klue OAuth Supply Chain Breach shows how third-party OAuth relationships can expand impact far beyond the initial login event. The broader issue is visibility: Astrix Security & CSA report that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps.
In practice, many security teams discover the abuse only after unusual mailbox access, API activity, or data exfiltration has already occurred, rather than through intentional app governance.
How It Works in Practice
OAuth apps bypass MFA by using the normal consent and token issuance flow, not by breaking the second factor itself. In a malicious consent scenario, the attacker tricks a user into approving a deceptive application that requests broad scopes such as mail, files, calendar, or directory access. Once consent is granted, the app receives a bearer token or refresh token that can be replayed without re-entering MFA for every request.
In attacker-in-the-middle phishing, the attacker proxies the sign-in flow, captures the session, and then uses the authenticated context to complete the OAuth grant. The result is the same operational problem: the attacker ends up with a valid token, cookie, or delegated permission that downstream services accept as legitimate. This is why NIST guidance on access control, including NIST SP 800-53 Rev 5 Security and Privacy Controls, matters here even though MFA is present. MFA protects authentication events; it does not automatically constrain what an authorised app can do afterward.
Operationally, strong programmes focus on four controls:
- restricting user consent to approved apps and verified publishers
- reviewing requested OAuth scopes before approval
- monitoring token issuance, refresh behaviour, and anomalous API use
- revoking high-risk grants quickly when an app is no longer trusted
That is why NHIMG guidance on the Ultimate Guide to NHIs is so relevant: OAuth apps are effectively non-human identities with standing access unless they are governed like workloads, not like one-time logins. These controls tend to break down in environments with broad self-service consent, legacy SaaS integrations, and weak vendor inventory because the organisation loses track of who granted what to which app.
Common Variations and Edge Cases
Tighter OAuth governance often increases friction for employees and administrators, requiring organisations to balance user productivity against consent risk. Current guidance suggests this tradeoff should be handled with tiered approval paths rather than blanket denial, especially where business-critical integrations depend on delegated access.
Some failures are more subtle than malicious consent. For example, stale refresh tokens can continue to work after a password reset, and compromised admin consent can silently authorise many users at once. In high-trust environments, a single approved application can also become a supply chain entry point, which is why NHIMG research on the Dropbox Sign breach is a useful reminder that the blast radius is often determined by integration scope, not login security alone.
Best practice is evolving toward conditional consent, token lifetime limits, publisher verification, and continuous review of non-human access. Where organisations have no app inventory, no consent policy, or no log correlation between identity provider events and SaaS API activity, the guidance breaks down quickly because security teams cannot distinguish a legitimate integration from a hostile one in time to act.
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, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF 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-03 | OAuth grants become persistent NHI credentials if they are not rotated or revoked. |
| OWASP Agentic AI Top 10 | A1 | Malicious apps behave like autonomous tool-using identities with delegated authority. |
| CSA MAESTRO | TRUST-03 | OAuth apps are third-party workload relationships that require runtime trust decisions. |
| NIST AI RMF | OAuth abuse shows why runtime governance and monitoring are needed for identity-driven systems. | |
| NIST CSF 2.0 | PR.AC-4 | OAuth app consent is an access control problem, not just an authentication problem. |
Inventory OAuth grants, revoke stale tokens, and enforce short-lived access with automated rotation.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
