TL;DR: Consent phishing turns legitimate OAuth consent prompts into persistent token-based access without stealing passwords, because users can approve scopes on the real identity provider and attackers then hold refresh tokens, according to WorkOS. The weak point is governance, not authentication: access review and password resets do not address delegated grants that outlive the session.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on WorkOS's blog post: OAuth consent phishing uses real identity provider prompts to obtain persistent delegated access through tokens rather than stolen passwords.
Why it matters: It matters because IAM teams must govern consent, scopes, and token lifetimes as access decisions, not assume authentication controls alone will contain OAuth abuse.
Context
OAuth consent phishing is an access governance problem inside OAuth 2.0 and OpenID Connect, not a password theft problem. The user approves permissions on the real identity provider, so the trust boundary sits at the consent prompt and the resulting delegated grant.
That matters for NHI governance because OAuth apps, refresh tokens, and delegated scopes behave like non-human access paths once consent is granted. Traditional phishing controls can miss the attack because the login is legitimate while the access decision is still unsafe.
Key questions
Q: What breaks when users can grant OAuth consent to risky applications?
A: The control that breaks is the assumption that a valid login equals safe delegated access. If users can approve powerful scopes for unknown or untrusted apps, attackers can convert a real consent flow into token-based access without stealing passwords or MFA codes. That makes consent policy a core access control, not a minor usability setting.
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 are the signs that OAuth consent governance is failing?
A: Common signs include broad scopes granted to unfamiliar applications, app registrations that survive beyond their business purpose, and consent events that are logged but not acted on. If reviewers only see the abuse in hindsight, governance is too slow for the risk level. The control needs policy, not just audit trails.
Q: Should organisations revoke refresh tokens immediately after a suspected consent phishing incident?
A: Yes. Password resets alone do not remove token-based access, so revocation has to be part of containment. Security teams should revoke the malicious application grant, invalidate the affected user’s refresh tokens, and review API activity tied to the app’s client ID before assuming the incident is contained.
Technical breakdown
How consent phishing abuses the OAuth authorization code flow
In a normal OAuth authorization code flow, the identity provider issues tokens after the user authenticates and approves scopes for a client application. Consent phishing keeps that protocol intact but corrupts the decision point: the attacker registers an app, sends the victim to the real authorization endpoint, and receives an authorization code after the user clicks Accept. The access token and refresh token then belong to the malicious client, not to the user session itself. Because the grant is valid at the protocol layer, the IdP does exactly what it was asked to do. The weakness is governance over who can consent, which scopes they can approve, and how long the resulting token can live.
Practical implication: treat consent permissions as an access control surface and restrict which users can create durable delegated grants.
Why consent grants evade familiar phishing and MFA controls
Consent phishing does not depend on fake login pages or credential capture. The authentication happens on the real identity provider domain, so safe-link checks, user training against spoofed domains, and successful MFA do not stop the attacker from obtaining a valid consented grant. Once issued, the token can call downstream APIs such as mail or file services without another interactive login. Depending on policy, those API calls may not trigger the same alerts as a sign-in event. That is why the attack survives password resets and often blends into ordinary application onboarding activity. The control gap is not authentication strength, but the absence of policy and detection around delegated authorization.
Practical implication: monitor consent events, not just sign-ins, and revoke delegated grants as part of incident response.
What refresh tokens change in post-consent persistence
Refresh tokens turn a single consent decision into a longer-lived access path. An access token may expire quickly, but a refresh token lets the attacker keep renewing access until revocation, inactivity timeout, or explicit expiry occurs. That means the attacker can continue reading mail, accessing files, or querying directory data long after the victim changes a password. In governance terms, the risky object is not the login session but the standing delegated authorization attached to the application. This is why OAuth sprawl becomes an NHI problem: the app is acting with persistent, user-approved access that survives the user’s normal authentication lifecycle.
Practical implication: shorten refresh token validity, inventory existing grants, and define revocation as a routine governance control.
Threat narrative
Attacker objective: The attacker wants durable, token-based access to user resources such as mail, files, and directory data without needing the password again.
- Entry occurs when the attacker lures the user to the real OAuth authorization endpoint and the victim authenticates on the legitimate identity provider.
- Credential access occurs when the victim approves the malicious app’s requested scopes and the attacker receives an authorization code, access token, and refresh token.
- Persistence follows because the refresh token keeps renewing access to mail, files, and directory data even after a password reset.
- Impact is unauthorized API access to the user’s resources through delegated OAuth permissions that can survive the original session.
Breaches seen in the wild
- Microsoft verified publisher OAuth phishing 2022: Malicious OAuth apps with a fraudulently obtained Microsoft verified publisher badge tricked UK users into granting mailbox access in 2022.
- Gitloker GitHub extortion campaign: Phishing via GitHub notifications tricked developers into authorising malicious OAuth apps; Gitloker then wiped repos and demanded contact.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Consent is the control plane, not the user click: OAuth consent prompts are access decisions that can outlive the authentication event itself. Once a user approves scopes on the real identity provider, the resulting grant behaves like a durable non-human access path with its own lifecycle. The practitioner conclusion is that consent governance belongs in the identity model, not in user awareness training alone.
Access review does not govern delegated authorization: Many identity programmes still treat OAuth grants as a by-product of login activity rather than as standing entitlements. That assumption fails when a refresh token preserves access after the session ends and after password resets. The implication is that recertification, grant inventories, and revocation workflows must cover delegated app access explicitly.
OAuth sprawl is the hidden NHI surface: Every unmanaged user consent expands the estate of applications acting on behalf of people. Over time, that produces the same governance problem seen with other non-human identities: unclear ownership, unclear scope, and unclear offboarding. The practitioner conclusion is that OAuth app governance has to be managed as part of NHI control, not as a separate SaaS convenience layer.
Identity provider trust was designed for legitimate delegation, not adversarial consent abuse: The model assumes the user can evaluate whether an application should receive scopes, and that assumption fails when attackers present requests inside a familiar login flow. The implication is not merely tighter policy, but a rethink of who is trusted to authorise durable access in the first place.
Named concept: consent-grant persistence gap: The attack works because the security model sees authentication events more clearly than delegated grants. That gap leaves the lasting object of risk, the OAuth consent itself, outside normal password and session governance. The practitioner conclusion is that consent events need their own lifecycle controls and detection logic.
From our research library:
- Security researchers tracked consent phishing campaigns affecting 900 tenants and 3,000 user accounts in 2025.
What this signals
Consent-grant persistence gap: The practical failure is not authentication weakness but the fact that a durable delegated grant survives the session that created it. Once that grant exists, password reset logic and ordinary sign-in monitoring are looking at the wrong object. The control boundary has to move to consent governance, revocation, and continuous grant review.
OAuth sprawl also changes the identity architecture question: every approved third-party app becomes a managed access path that needs ownership, scope review, and offboarding. Teams that already govern service accounts and API keys should recognise the same lifecycle pattern here, because the security issue is durable non-human access approved through a human action.
For practitioners
- Restrict user OAuth consent Block broad self-consent where possible and allow only verified, low-risk apps to receive user-granted scopes without review.
- Stand up an admin approval workflow Route user requests for new OAuth access to security or platform reviewers, and require the business purpose, publisher status, and requested scopes to be checked.
- Inventory existing OAuth grants Review current consent grants and app role assignments for broad scopes, unverified publishers, and refresh tokens that remain active without recent use.
- Tune detection for consent events Alert on new OAuth grants for sensitive scopes and correlate them with recent phishing delivery, unusual publishers, and newly created client IDs.
- Shorten token persistence Reduce refresh token lifetime where policy allows and build revocation into incident response so token-based access does not survive a compromise window.
Key takeaways
- Consent phishing succeeds because the trust decision sits at the OAuth consent screen, where users can grant durable access without compromising their password.
- The article shows that token-based persistence can survive password changes, which makes delegated grants a distinct governance problem from interactive authentication.
- The practical control shift is to manage consent, scopes, and refresh tokens as lifecycle assets that require inventory, review, and revocation.
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 centres on abused OAuth consent and token issuance inside a legitimate identity flow. |
| NHI-07 — Long-Lived Secrets | Refresh tokens create the persistence window that keeps consent phishing alive after login ends. | |
| NHI-10 — Human Use of NHI | Users are making security decisions on behalf of applications, which creates governance risk over non-human access. | |
| Recommendation — Tighten OAuth consent paths so attackers cannot turn legitimate authentication into durable delegated access. Shorten refresh token lifetime and revoke standing grants when consent is no longer justified. Govern who can authorise application access and require review for user-granted permissions. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Token and refresh-token lifecycle control is central to limiting post-consent persistence. |
| Recommendation — Apply authenticator lifecycle controls to expire and revoke OAuth tokens on a governed schedule. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | OAuth consents are entitlements that need explicit governance, review, and revocation. |
| Recommendation — Govern OAuth grants as entitlements and review them with the same rigor as other access permissions. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | The attack obtains token-backed access and then uses it to collect mail and files. |
| Recommendation — Map consent-phishing detections to token-based credential access and downstream data exfiltration. | ||
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.
- 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.
- 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 Grant: An OAuth grant is the delegated permission an application receives to act on a user's behalf without storing the user's password. In NHI governance, it should be treated as a standing identity relationship with scope, ownership, and revocation requirements, not as a one-time setup 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.
Published by the NHIMG editorial team on June 6, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org