Consent phishing exposes the authorization gap in SaaS and NHI security

At a glance

What this is: This is an analysis of consent phishing, where attackers use OAuth consent flows to gain persistent access to SaaS resources without stealing passwords.

Why it matters: It matters because IAM and NHI teams must govern delegated access, token scope, and revocation, not just human authentication events.

By the numbers:

• The attack targeted at least 35 commonly used Chrome browser extensions including Cyberhaven.

👉 Read Valence Security's analysis of OAuth consent phishing and MFA bypass

Context

Consent phishing is a delegated-access abuse pattern, not a password theft problem. The user is tricked into approving an OAuth application, and that approval gives the attacker a non-human identity with API-level access that MFA does not meaningfully constrain.

For IAM and NHI practitioners, the governance gap is the authorization layer. When third-party apps, tokens, and permission scopes are not continuously reviewed, organizations can have strong login controls and still lose control of data, mail, files, and admin workflows.

Key questions

Q: How should security teams handle OAuth consent risk in SaaS environments?

A: Treat OAuth consent as an access control event, not a simple user choice. Review app scopes, owner approval, and token lifetime before allowing access. Then monitor the resulting API activity for data exfiltration, mailbox rule changes, and unauthorized automation. Consent without governance becomes persistent access, especially when the app can act outside the user’s normal session controls.

Q: Why does MFA not stop consent phishing?

A: MFA only strengthens the login step. Consent phishing abuses the authorized session after the user approves a malicious app, so the attacker inherits legitimate token-based access. The control gap is in delegated authorization, not authentication. Teams need consent review, app allowlisting, and token revocation because MFA cannot judge whether the requested permissions are safe.

Q: What is the difference between password theft and OAuth abuse?

A: Password theft steals credentials used to sign in, while OAuth abuse exploits permission that the user has already granted to an app. The second path can bypass repeated authentication and keep working until the token is revoked. That is why OAuth abuse is an authorization-layer problem, not just an account compromise problem.

Q: When should organisations revoke OAuth tokens?

A: Revoke tokens whenever the app owner is unknown, the requested scope is excessive, the integration is inactive, or the app behavior changes unexpectedly. Also revoke after a phishing event, suspected mailbox compromise, or platform-wide audit. The safest posture is to treat stale delegated access as a standing security liability until proven necessary.

Technical breakdown

How OAuth consent becomes persistent NHI access

OAuth 2.0 is designed to let applications act on behalf of a user through delegated authorization. In consent phishing, the attacker does not need the victim’s password after the initial lure. Instead, the user approves a malicious app and the platform issues an authorization code or token that can be exchanged for API access. That token can remain valid until revoked, which makes the resulting access a non-human identity issue as much as an identity theft issue. MFA protects the login step, but it does not automatically inspect whether the requested scope is excessive or whether the app itself should be trusted.

Practical implication: Review delegated app grants as identity events and enforce scope approval, token revocation, and app trust checks.

Why MFA fails against OAuth abuse

MFA is effective when the control point is authentication to a human account. Consent phishing shifts the abuse path to post-authentication authorization, where the attacker uses the user’s legitimate approval to gain access through an API session. The security problem is that the platform treats the granted permission as valid even when the requesting app is malicious. That means the threat lives in the relationship between identity, application, and permission scope. Conditional access can reduce risky sign-ins, but it does not replace controls that inspect third-party integrations, consent events, and token usage over time.

Practical implication: Pair MFA with consent governance, app allowlisting, and continuous monitoring of OAuth sessions.

Third-party integrations and permission scope are the real attack surface

The article points to a familiar SaaS pattern: unmanaged integrations, over-privileged scopes, and long-lived tokens create durable access paths. Once a malicious app is granted read and write permissions, the attacker can exfiltrate data, manipulate APIs, or persist in the environment without repeated user interaction. This is why consent phishing often looks less like classic phishing and more like governance failure across the SaaS authorization layer. The security boundary is no longer just the account. It is the combination of app registration, consent, scope, and token lifecycle.

Practical implication: Inventory third-party SaaS integrations and remove any app whose scope cannot be justified and monitored.

Threat narrative

Attacker objective: The attacker wants durable API-level access to SaaS data and workflows that survives MFA and outlasts the initial phishing event.

1. Entry occurs when the attacker sends a spear phishing message that lures the victim to a legitimate-looking consent screen.
2. Escalation happens when the victim approves broad OAuth permissions, allowing the attacker to mint a token for API access.
3. Impact follows when the attacker uses that token to read, write, exfiltrate, or persist across SaaS resources without needing the password again.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.

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 NHI governance failure, not just a phishing variant. The decisive mistake is treating OAuth approval as a low-risk user action when it actually creates an application identity with durable access. MFA can verify a person at sign-in, but it does not govern what a granted token can do afterward. Practitioners should treat consent events as privileged access events.

Long-lived delegated access creates an identity blast radius that most SaaS teams do not measure. Once a token is granted, its effective scope can exceed the user’s intent and persist beyond the initial session. That creates a blast radius problem, not merely a detection problem. Teams need revocation speed, scope review, and integration governance as first-class controls.

Authorization-layer controls now matter as much as authentication controls. The industry has spent years hardening login flows, yet attackers are moving to the point where permissions are created and persisted. That shift validates an IAM model that includes app consent review, token inventory, and runtime monitoring. Security teams should assume that identity compromise can now happen without a password theft event.

Ephemeral trust debt is the right way to describe consent phishing exposure. A user can create high-risk trust that looks temporary but remains operational until it is explicitly removed. The debt accumulates when organizations fail to track third-party apps, scope creep, and stale tokens. The practical answer is continuous governance of every delegated authorization.

Consent phishing should be evaluated alongside NHI sprawl and shadow integrations. The problem is not only malicious apps, but also the legitimate ecosystem of unmanaged OAuth relationships that attackers can mimic or exploit. That makes discovery and classification the starting point for governance. Practitioners should map who can grant what, to which app, and for how long.

From our research:

• 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, according to The State of Non-Human Identity Security.
• Only 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which explains why delegated access remains hard to govern at scale.
• A useful next step is to pair governance with lifecycle controls by reviewing NHI Lifecycle Management Guide for provisioning, rotation, and offboarding practices.

What this signals

Consent phishing will push SaaS teams toward authorization governance as a default control domain. As more access is brokered through app consent and tokens, teams will need a control plane that tracks who granted what, to whom, and for how long. The operational question is no longer only whether the user authenticated, but whether the resulting delegated access is still justified.

Ephemeral access does not equal low risk if revocation is weak. The real measure is not how quickly a token is issued, but how quickly it can be discovered, assessed, and removed when behavior changes. That is where identity lifecycle discipline matters, and it aligns closely with the NHI Lifecycle Management Guide.

With 85% of organisations lacking full visibility into third-party vendors connected via OAuth apps, per The State of Non-Human Identity Security, consent phishing is a visibility problem as much as a deception problem. Security programmes should prepare for more shadow integrations, not fewer.

For practitioners

• Audit all third-party OAuth grants Inventory every consented application across Microsoft 365, Google Workspace, GitHub, and other SaaS platforms. Identify apps with mail, file, repo, or admin scopes and remove any grant that lacks a documented business owner.
• Require explicit scope review for high-risk permissions Route requests for read and write access, offline access, and admin-level scopes through a governance workflow before approval. Block blanket consent unless the app is on an approved list and the scope is time-bound.
• Monitor token usage after consent Correlate consent events with unusual API activity, new mailbox rules, mass downloads, and atypical repo actions. Revoke tokens immediately when the app behavior diverges from the approved use case.
• Reduce standing delegated access Apply just-in-time approval where possible and shorten token lifetimes for sensitive integrations. Revalidate legacy integrations quarterly and remove any OAuth relationship that has not been actively used.

Key takeaways

• Consent phishing turns user approval into persistent non-human access, which makes it a governance issue as much as a fraud issue.
• The cited campaigns show that a single malicious OAuth grant can affect millions of users and dozens of extensions, proving the blast radius is real.
• Security teams should move from sign-in-centric controls to consent review, scope management, and token lifecycle governance.

Key terms

• Consent Phishing: A social-engineering attack that tricks a user into granting an application access through a legitimate OAuth consent screen. The result is delegated access that can persist after the initial login and can bypass MFA because the abuse happens through authorized tokens, not stolen passwords.
• 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.
• OAuth Token: A credential issued by an authorization server that lets an app access resources within approved scopes. Tokens are central to modern SaaS access and become a security liability when they are long-lived, over-privileged, or left unmonitored after the app is no longer trusted.
• Identity Blast Radius: The amount of damage that can result when one identity or delegated grant is abused. For non-human identities, blast radius is driven by scope, token lifetime, connected systems, and the speed of revocation, making it a useful measure for prioritizing controls.

Deepen your knowledge

Consent phishing, OAuth abuse, and delegated access governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for SaaS integrations and token lifecycle management, it is worth exploring.

This post draws on content published by Valence Security: The Rising Threat of Consent Phishing: How OAuth Abuse Bypasses MFA. Read the original.