Consent phishing exposes the authorization gap in OAuth identity models

At a glance

What this is: This analysis shows how illicit consent grants turn real OAuth login flows into durable delegated access, often without malware, password theft, or endpoint compromise.

Why it matters: IAM teams need to treat consent, token scope, and app registration as governed access paths because delegated authorisation can bypass the assumptions behind MFA-centric controls.

By the numbers:

• NHIs outnumber human identities by 25x to 50x in modern enterprises.
• Only 5.7% of organisations have full visibility into their service accounts.
• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.

👉 Read SlashID's analysis of OAuth consent phishing and token abuse

Context

Consent phishing is an OAuth authorization abuse pattern, not a classic credential theft event. The user signs in to a real identity provider, approves a malicious application, and the attacker receives a token that can act with delegated access under the victim's permissions. For IAM teams, the problem is that the trust decision moves from authentication to consent, where many controls are weaker and less reviewed.

That shift matters because modern identity programmes often over-focus on login security while under-governing app consent, service principal lifecycle, and token scope. The result is a gap between who authenticated and what was authorised. This is a direct identity governance problem for both human access and the non-human identities created by delegated applications.

Key questions

Q: How should security teams govern OAuth 2.0 in enterprise environments?

A: Security teams should govern OAuth 2.0 as a delegated access model with lifecycle controls. That means inventorying clients, limiting scopes, reviewing grants on a schedule, and revoking stale tokens and client secrets. OAuth is safest when it is treated as managed NHI behaviour rather than a one-time integration choice.

Q: Why do AiTM phishing kits still succeed against MFA?

A: AiTM kits succeed because they capture the authenticated session, not just the password. If the attacker can intercept the one-time code and the session cookie during login, MFA has already done its job and the cookie becomes the reusable credential. Defenders therefore need controls that watch for session replay and token abuse after sign-in.

Q: What breaks when organisations only monitor sign-in events and ignore consent grants?

A: They miss the event that actually creates delegated access. Sign-in telemetry can look normal because the user logged in to the legitimate provider, while the malicious application receives token-based access afterward. Without monitoring grants, token issuance, and refresh activity, the attacker can persist with little or no obvious interactive login trail.

Q: Who is accountable when a malicious OAuth application is approved by a user?

A: Accountability sits with the organisation that allowed user-granted access to sensitive scopes without sufficient policy control, review, or monitoring. The user made the click, but the governance model defined the blast radius. Security, IAM, and application owners all need clear ownership for approval policy and token revocation.

Technical breakdown

How illicit consent grants turn OAuth into standing access

OAuth 2.0 delegated authorization lets a user approve an application to act within defined scopes, then receive access and refresh tokens. In a consent-phishing attack, the attacker registers an app, asks for high-value scopes such as mailbox or file access, and gets the victim to approve the request through a real identity provider. Because the flow is legitimate, the tokens are issued by the platform itself and can look indistinguishable from normal application activity.

Practical implication: govern app consent, scope approval, and token revocation as first-class identity controls.

Why MFA does not stop consent-based token theft

MFA proves the user authenticated, but it does not prove the application should be trusted. The attacker does not need to intercept the password or second factor because the grant happens after successful login. Once the user accepts the app, the identity provider issues tokens that can be redeemed server-side, often without further interactive prompts. That is why the compromise survives password resets and MFA re-enrolment unless the malicious grant itself is removed.

Practical implication: build detection and revocation around grants, not just sign-in events.

Why low-code agent workflows expand the abuse surface

The CoPhish case shows how editable workflow topics in a low-code agent can embed token forwarding after a legitimate sign-in step. The attacker does not need to break the platform; they abuse the app's own logic to move the token from the user session into attacker-controlled infrastructure. That changes the trust boundary from endpoint security to workflow governance, where hidden HTTP actions and backend token handling can create durable exposure.

Practical implication: review agent and workflow configurations for hidden token handling and post-auth exfiltration paths.

Threat narrative

Attacker objective: The attacker wants durable API or mailbox access that survives the initial consent event and can be renewed without the user's presence.

1. Entry occurs when an attacker lures the victim into a real OAuth authorize flow from a plausible application registration and trusted identity-provider domain.
2. Escalation occurs when the victim consents to high-value delegated scopes, allowing the attacker to exchange the authorization code for access and refresh tokens.
3. Impact occurs when the attacker uses those tokens to access mail, files, chat, or other APIs as the approved application, creating standing delegated access.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

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 is not a side effect of authentication, it is an identity control point. OAuth abuse works because many programmes treat the login event as the end of security review. In reality, the approval of a third-party application is a separate governance decision that can create standing delegated access. IAM teams that do not review consent flows, app registration privileges, and scope grants are leaving a parallel access path outside normal certification.

Delegated authorization creates a non-human identity even when the user is human. The approved application becomes the actor that consumes tokens and calls APIs, so the control model has to shift from user authentication to application lifecycle governance. That is where OWASP Non-Human Identity Top 10 and NHI lifecycle thinking become relevant, because the risk is no longer only the person who clicked Accept, but the token-bearing application left behind.

Editable workflow automation turns consent phishing into hidden token movement. In the CoPhish pattern, the dangerous step is not the login prompt alone but the post-auth HTTP action that forwards the token away from the platform. That is a governance failure around workflow integrity, app modification rights, and secret handling inside low-code tools. Practitioners should treat these workflows as identity-bearing systems, not harmless productivity glue.

Consent phishing exposes an authorization gap, not an MFA gap. The control assumption that strong authentication equals safe access breaks when the actor can request broader permissions after sign-in. Security programmes that measure only login strength miss the real attack surface, which is app consent, token scope, refresh token durability, and revocation latency. The practical conclusion is that authorization governance must stand beside authentication governance.

From our research:

• NHIs outnumber human identities by 25x to 50x in modern enterprises, according to Ultimate Guide to NHIs.
• From our research: Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• For a broader breach pattern, review 52 NHI Breaches Analysis to see how standing access and delegated trust repeatedly turn into exposure.

What this signals

Consent-event governance will become a core IAM control domain. Teams that still measure only authentication quality will keep missing the event that creates delegated access. As OAuth, low-code agents, and SaaS integrations proliferate, consent reviews need to sit beside role reviews, privileged access reviews, and lifecycle controls in the same governance rhythm.

App registration and token lifecycle will increasingly define the real blast radius. The practical question is no longer whether MFA was used, but how quickly malicious grants can be discovered and removed once a user has approved them. That shift aligns closely with the governance model in the Ultimate Guide to NHIs.

Consent phishing is a reminder that identity trust now extends into workflow systems. Low-code automation, agent builders, and third-party apps all create non-human actors that can move tokens and data without endpoint malware. Security programmes need to assume that the approval event is only the beginning of the risk window.

For practitioners

• Inventory all OAuth apps and service principals Map every app that can request delegated access, especially those with mail, files, chat, offline_access, or admin-consent scopes. Separate approved internal apps from user-consented third-party apps and mark dormant or over-permissioned grants for review.
• Restrict application registration and user consent Remove broad user consent where possible, require admin approval for sensitive scopes, and monitor tenant settings that let ordinary users register applications. Pair that with attestation for high-risk consent pathways.
• Revoke grants, not just sessions Build a revocation workflow that disables the service principal, removes the OAuth grant, rotates any exposed credentials, and terminates active sessions when suspicious consent is detected.
• Review low-code agent workflows for post-auth token handling Inspect system topics, HTTP actions, and hidden backend calls in Copilot-style environments to confirm that tokens are not forwarded to external endpoints after authentication.
• Add consent-event monitoring to your identity reviews Treat consent-to-application events as reviewable identity activity alongside sign-ins, privileged role changes, and refresh token issuance so that delegated access is visible in governance reports.

Key takeaways

• Consent phishing succeeds because it abuses delegated authorization after a legitimate sign-in, not because it defeats MFA.
• The exposure can be durable because access tokens and refresh tokens outlive the moment the user clicked Accept.
• Teams need to govern app consent, token revocation, and workflow token handling as part of identity security, not as separate app hygiene tasks.

Key terms

• Illicit Consent Grant: A malicious OAuth approval that gives an application delegated access to user or tenant data through a legitimate identity provider. The user authenticates normally, but the attacker persuades or tricks them into authorizing scopes that create durable token-based access.
• Refresh Token: A longer-lived credential that can mint new access tokens without forcing the user to authenticate again. Because refresh tokens can preserve access for extended periods, they are a major governance concern when malicious or over-scoped applications are granted consent.
• Service Principal: An application identity object in Microsoft Entra ID and Microsoft 365 that represents a specific app inside a tenant. It holds permissions, ownership, and configuration data that define what the application can do. In NHI governance, it is a high-value identity that should be reviewed like any other privileged account.

What's in the full article

SlashID's full research covers the operational detail this post intentionally leaves for the source:

• The full consent-phishing chain from authorize request to token exchange, including the scopes and token types involved.
• The Copilot Studio abuse path, including editable system topics and the post-auth HTTP Request action.
• Detection and remediation workflows for suspicious grants, risky service principals, and active token abuse.
• Operational guidance on how browser extension visibility can surface dangerous OAuth approvals before tokens are misused.

👉 SlashID's full post covers the consent chain, CoPhish workflow abuse, and remediation detail.

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 building or maturing an IAM programme, it is worth exploring.