TL;DR: Consent phishing uses legitimate OAuth consent flows to obtain persistent SaaS access, bypassing MFA because the attacker abuses delegated authorization rather than stolen credentials, according to Valence Security. The pattern shows that NHI governance must extend beyond login controls into token lifecycle, permission scope, and third-party integration monitoring.
At a glance
What this is: This is an analysis of consent phishing, where attackers exploit OAuth consent flows to gain persistent SaaS access without stealing passwords.
Why it matters: It matters because IAM and NHI programmes that stop at authentication miss the delegated authorization layer where OAuth tokens, third-party app scopes, and revocation controls determine real exposure.
Context
Consent phishing is a delegated authorization attack, not a credential theft event. The victim approves a legitimate OAuth consent screen, which gives the attacker access through an application token instead of a stolen password or intercepted MFA challenge. That matters for SaaS security because the control failure sits in authorization governance, not at the login prompt.
For IAM and NHI teams, the important shift is that access now persists through tokens, app permissions, and third-party integrations. If those entitlements are not inventoried, reviewed, and revoked with the same discipline used for user accounts, attackers can keep operating after the initial deception ends.
The article’s starting point is typical of modern SaaS risk: a familiar workflow being repurposed as an access path. The problem is not that OAuth is broken, but that many programmes still treat delegated access as a secondary concern instead of part of the identity control plane.
Key questions
Q: What breaks when OAuth consent is not centrally governed?
A: When consent is not centrally governed, employees can grant third-party apps persistent access to enterprise data without security review. That breaks the assumption that only procured vendors can reach sensitive systems. The result is shadow access that bypasses inventory, risk assessment, and lifecycle control, leaving identity teams blind to delegated privileges already inside the tenant.
Q: Why are OAuth tokens such a persistent SaaS security risk?
A: OAuth tokens are persistent because they often bypass MFA, carry broad delegated permissions, and remain valid long after the original approval. That combination creates durable access for attackers if a token is stolen or abused. The problem is amplified when organisations lack full visibility into connected apps and do not review grants regularly.
Q: What are the signs that consent phishing is creating hidden access paths?
A: Look for newly approved apps with broad read-write scopes, tokens created outside normal onboarding, and API activity that does not match the user’s usual workflow. Those signals show that delegated access has become the real control surface and that sign-in telemetry alone is not enough to explain the exposure.
Q: How should teams govern third-party SaaS integrations after a consent event?
A: Treat every consented app as a governed identity with an owner, a scope, an expiry or review point, and a revocation path. If the integration cannot be justified, monitored, and removed quickly, it should not be allowed to keep acting on behalf of the organisation.
Technical breakdown
How OAuth consent becomes persistent access
OAuth consent is designed to let a user grant an application scoped access without sharing their password. In a consent phishing flow, that same delegation step is abused: the attacker presents a legitimate consent page, the user approves requested scopes, and the application receives an authorization code that can be exchanged for a token. From that point, access is driven by token scope and token lifetime, not by the original login event. The critical shift is that the attack survives MFA because MFA only protects the user authentication step, not the delegated authorization the user has already approved.
Practical implication: govern OAuth grants as access objects, not just login events.
Why MFA does not stop consent phishing
MFA verifies that the user who logged in is the expected person. Consent phishing bypasses that protection by asking the user to authorize a malicious application after authentication has already succeeded. The attacker is not trying to defeat the MFA factor directly. Instead, they use a valid session to obtain an OAuth token with the permissions the user approved. Once that token exists, subsequent API calls operate inside the granted scope, which means the security boundary shifts from interactive authentication to delegated authorization.
Practical implication: pair MFA with consent governance, app review, and token revocation.
Why third-party integration monitoring is the control gap
Third-party integrations create a second identity surface inside SaaS platforms. Every approved app, service connection, and tokenized workflow adds an entitlement path that can outlive the session that created it. If organisations only monitor user sign-ins, they miss the ongoing use of application tokens, including read, write, and file access granted through consent. This is why the article treats OAuth tokens as non-human identities in practice: they act independently of the human login and can remain active until explicitly revoked.
Practical implication: inventory all approved integrations and continuously review their scopes and activity.
Threat narrative
Attacker objective: The attacker’s objective is durable SaaS access through delegated authorization, with enough scope to manipulate data, exfiltrate content, and remain active after the initial phishing interaction.
- Entry occurs when a spear phishing message lures the victim into opening a legitimate-looking OAuth consent page for a cloud application.
- Credential_harvested is not the right pattern here because the attacker instead captures delegated authorization by persuading the user to approve risky permissions.
- Escalation follows when the attacker exchanges the authorization code for an OAuth token and uses that token to call SaaS APIs within the granted scope.
- Impact is persistent access to emails, files, contacts, or other SaaS data until the token or application grant is revoked.
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.
- 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 our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Consent phishing is an authorization-layer problem, not a login problem. The attack works because the user completes a legitimate consent flow, which means traditional authentication controls have already done their job. What fails is the assumption that identity risk ends when MFA succeeds. The practitioner implication is that SaaS security must govern delegated access with the same seriousness as primary authentication.
OAuth tokens are effectively non-human identities with their own lifecycle. Once consent is granted, the token can continue to act independently of the user who approved it, which makes token scope, token lifetime, and revocation the real control plane. That is why this is an NHI issue as much as an IAM issue. Teams need to treat app grants and integration entitlements as governed identities, not incidental by-products of user activity.
Persistent authorization creates identity blast radius. A single approved application can inherit broad read and write permissions across mail, files, and contacts, then remain active until explicitly removed. That turns one deceptive click into an extended access path across the SaaS estate. Practitioners should read this as a lifecycle failure: grants are created quickly, but too often they are never certified or offboarded.
Consent phishing exposes the authorization gap in SaaS security. The security model still overweights authentication and underweights post-consent monitoring, which is where abuse now concentrates. Conditional access helps at sign-in time, but it does not continuously evaluate the security posture of approved applications. The implication is clear: entitlement review must move closer to the authorization event itself.
From our research library:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
- Security researchers tracked consent phishing campaigns affecting 900 tenants and 3,000 user accounts in 2025.
- Read next: NHI Lifecycle Management Guide
What this signals
Consent phishing is the clearest example of the authorization gap inside SaaS programmes. Conditional access and MFA still matter, but they do not govern what happens after a user approves an application. The control point has moved to the consent event, where delegated access, app ownership, and revocation discipline determine whether the grant becomes a standing risk.
Delegated access needs lifecycle governance, not just security review. Every approved OAuth app creates a token-backed entitlement that should be reviewed, certified, and retired like any other identity. If organisations continue to separate user authentication from application authorization, they will keep missing the place where modern SaaS compromise actually persists.
For practitioners
- Audit OAuth grants and consented apps Inventory all approved third-party applications, classify their scopes, and remove any grant that no longer has a business owner or clear use case.
- Revocation trigger for suspicious consent Create a response path that revokes OAuth tokens and application permissions as soon as an unapproved consent grant or abnormal API use is detected.
- Restrict high-risk permission scopes Block or require review for apps requesting mail, file, contact, or admin scopes unless the integration is explicitly approved and monitored.
- Monitor third-party integration activity Track token creation, scope expansion, and API calls from SaaS integrations so that delegated access is visible outside the human sign-in record.
Key takeaways
- Consent phishing turns a legitimate OAuth approval into persistent SaaS access, which means the weak point is delegated authorization rather than password theft.
- The exposure is amplified by token scope, third-party integrations, and the fact that approved applications can keep operating until someone revokes them.
- Security teams should move control ownership from the login screen to the consent event, integration inventory, and token revocation workflow.
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 CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | OAuth tokens function as high-value secrets once consent is granted and can be abused outside the login flow. |
| NHI-04 — Insecure Authentication | The article shows that authentication alone does not protect delegated SaaS access after consent is approved. | |
| NHI-07 — Long-Lived Secrets | Consent phishing becomes dangerous when OAuth tokens remain valid long enough to provide persistent access. | |
| Recommendation — Inventory OAuth tokens as secrets and revoke any grant that lacks a clear owner or current business purpose. Separate authentication checks from consent governance so approved applications are still subject to review. Shorten token lifetimes and revoke stale OAuth grants before they become standing access paths. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Consent phishing abuses authorization scope, which falls squarely into entitlement governance. |
| Recommendation — Apply entitlement reviews to SaaS app grants and verify that scopes match the intended business use. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | The attack uses authorization abuse to gain access and then move data through SaaS APIs. |
| Recommendation — Map consent phishing telemetry to credential-access and exfiltration patterns in your detection pipeline. | ||
Key terms
- Consent Phishing: A social engineering attack that persuades a user to approve a malicious OAuth application. The attacker gains delegated access through legitimate authorization rather than stealing a password, which makes the resulting token-based access harder to detect and revoke than a normal sign-in compromise.
- OAuth Token: A short-lived access credential issued by an OAuth 2.0 authorisation server granting an NHI scoped access to specific resources for a defined period. Preferred over static API keys because their short lifetime limits the exploitation window if intercepted.
- Delegated Authorization: A model in which an application is allowed to act on a user’s behalf after explicit approval. In SaaS environments, delegated authorization is powerful but risky because excessive scope or weak revocation can turn a routine integration into durable non-human access.
- Third-Party Integration Risk: Third-party integration risk is the chance that external services, APIs, or partner accounts create an unintended route into internal systems. These connections often bypass traditional perimeter assumptions, so they need the same identity, segmentation, and review discipline as internal access.
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 May 28, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org