Device code phishing steals OAuth tokens via legitimate SaaS login

At a glance

What this is: NHI Mgmt Group's analysis, drawing on AppOmni's blog post: Device code phishing abuses legitimate OAuth device flows to steal valid tokens and expand SaaS compromise beyond Microsoft 365.

Why it matters: IAM and security teams need to treat OAuth grants, connected apps, and token scope as first-class identity controls because phishing-resistant authentication alone does not stop consent-layer abuse.

Context

OAuth device code phishing is a consent-layer attack, not a password attack. The victim signs in on the legitimate identity provider, but the attacker controls the device that receives the resulting tokens. That breaks the assumption that stronger authentication alone can contain phishing risk, especially in SaaS environments where connected applications and delegated access are already common.

The governance gap is visibility into authorisation, not just into login success. When an attacker can turn a normal device flow into a valid token grant, the control boundary moves from the sign-in screen to the approval event and the downstream use of the token.

Key questions

Q: Why do device code phishing attacks bypass many standard phishing controls?

A: They use the real Microsoft login page, so there is no fake domain, no malicious payload, and no obvious infrastructure to block. The victim completes MFA willingly, which makes the sign-in look legitimate to many tools. Detection has to move to token issuance, unusual device-code use, and post-authentication behaviour instead of URL reputation alone.

Q: Why do phishing-resistant MFA methods not stop token theft?

A: Phishing-resistant MFA reduces credential replay by binding the second factor to the legitimate authenticator, but it does not stop an attacker who steals an already issued session cookie, refresh token, or bearer token. Once a token is valid, the system often treats the caller as authenticated until expiry, revocation, or conditional access re-evaluation.

Q: How should security teams govern OAuth grants when employees connect shadow AI and SaaS apps at scale?

A: Security teams should treat OAuth grants as standing access paths that need continuous review, not one-time approval. Prioritise discovery across identity, browser, inbox, and connected apps, then apply policy-based analysis to identify excessive scopes, unusual app combinations, and dormant high-risk access. Remediation should be human-in-the-loop, so revocations match business context and avoid unnecessary disruption.

Q: What is the difference between access tokens and refresh tokens in OAuth risk management?

A: Access tokens are short-lived credentials used for immediate API calls, while refresh tokens extend access by allowing new tokens to be issued without reauthentication. For security teams, the key difference is persistence: refresh tokens and the grants behind them keep trust alive after a session ends, so revocation matters as much as expiration.

Technical breakdown

How the OAuth device authorization grant is abused

The OAuth 2.0 device authorization grant was designed for constrained devices that cannot present a normal browser-based login. The user is asked to complete authentication on a separate device, then the original device exchanges the code for access and refresh tokens. Device code phishing keeps the protocol intact while swapping the requester behind the code. The user cannot reliably see whether the code came from a smart TV, a CLI tool, or an attacker-controlled script. That asymmetry is what makes the flow exploitable. Read OAuth 2.0 and OpenID Connect Guide for Identity Teams.

Practical implication: Treat device authorization as a high-risk grant path and evaluate whether the business case justifies keeping it enabled.

Why phishing-resistant MFA does not close token theft

FIDO2, passkeys, and other phishing-resistant methods reduce credential replay, but they do not stop an attacker from persuading a user to authenticate on the real identity provider. In device code phishing, the MFA ceremony happens exactly where it should, so the IdP sees a legitimate user action and issues valid tokens. The weakness is not the authentication factor itself. It is the fact that the token is issued to a device the user cannot verify in the approval step. See the Passwordless and Passkeys Guide.

Practical implication: Shift detection and policy controls from credential entry to consent, token issuance, and application authorisation behaviour.

Why refresh tokens make the compromise persist

Once issued, refresh tokens can outlive the original interaction and continue to mint access tokens until they expire or are revoked. That persistence means password reset alone is often insufficient after device code phishing, because the attacker may still hold a valid token chain. In SaaS environments, that can extend access to mail, files, APIs, or developer resources depending on the scopes granted. The operational problem is token survivability after the victim has already completed a legitimate login. Read the Ultimate Guide to NHIs: What are Non-Human Identities.

Practical implication: Build incident response around token revocation and connected app review, not only around password reset.

Threat narrative

Attacker objective: The attacker wants durable, valid access to SaaS resources without needing the victim's password or a fake login page.

1. Entry occurs when the attacker obtains a device code through phishing, vishing, or a lured authorization request that uses a legitimate OAuth device flow.
2. Credential harvesting happens when the victim completes authentication on the real identity provider and the flow returns valid access and refresh tokens to the attacker-controlled device.
3. Escalation follows when the attacker reuses the token to access SaaS data, connected applications, or federated services with whatever scopes were approved.
4. Impact comes from persistent access that survives the password change and can extend into repositories, business applications, or downstream SSO resources.

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.
• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Device code phishing is a consent abuse problem, not a credential theft problem: the attacker wins by persuading the user to approve a legitimate OAuth flow on the real identity provider. That means the strongest password controls can be bypassed without ever being attacked directly. Practitioners should stop treating this as a variant of classic phishing and treat it as an authorisation-path compromise.

Consent governance becomes the control plane when OAuth tokens replace passwords: once the victim authorises a device flow, the security decision shifts from login verification to token issuance and app approval. The article's platform examples show that the same abuse pattern can repeat across Microsoft 365, Salesforce, GitHub, and identity providers, so connected application governance must be consistent across the SaaS estate.

Token persistence outlasts the user's recovery actions: refresh tokens extend the life of the compromise long after a password reset or help-desk intervention. This is why incident handling for SaaS account compromise must include token revocation, connected app review, and downstream session invalidation, not just account recovery.

OAuth device flow is a protocol-level trust exception that attackers can industrialise: AppOmni's examples show the same social engineering pattern being adapted across vendors, which means the issue is not one platform's implementation but the broader assumption that device-flow approvals are low-risk. Practitioners should treat any exposed device flow as a standing opportunity for identity-layer abuse.

Device code phishing exposes an identity governance blind spot across SaaS ecosystems: organisations often inventory users and passwords more carefully than grants, scopes, and connected apps. The practical consequence is that the attack is easiest to miss exactly where the lasting access is created, so governance has to move to authorisations, not just logins.

From our research library:

• Security researchers tracked consent phishing campaigns affecting 900 tenants and 3,000 user accounts in 2025.

What this signals

Consent-layer defence will matter more than login-layer hardening: as attackers keep shifting from password theft to token theft, the decisive controls move to authorisation policy, app trust, and token revocation. Security teams that still measure resilience mainly through MFA coverage will miss the place where the compromise actually persists.

App governance is becoming part of identity security operations: connected applications, approved scopes, and delegated permissions now need the same operational attention once reserved for passwords and sessions. The practical shift is toward continuous review of who can authorise what, under which publisher trust model, and with what downstream reach.

For practitioners

• Disable unused OAuth device flows Remove the device authorization grant wherever business processes do not require it, especially on high-value SaaS and identity platforms.
• Restrict user consent to approved publishers Require administrative approval for high-risk scopes and block unverified or unknown publishers from gaining tenant-wide trust.
• Inventory connected applications continuously Track every OAuth grant, delegated scope, and connected app so that suspicious approvals can be detected and revoked quickly.
• Monitor identity-layer indicators of abuse Alert on unusual token issuance, new app authorisations, abnormal device registration, and repeated consent prompts that do not fit normal user behaviour.
• Revoke tokens as part of incident response Treat password resets as incomplete until refresh tokens, active sessions, and any attacker-approved applications have been revoked.

Key takeaways

• Device code phishing works because it converts a legitimate OAuth approval into attacker-owned token access without needing a stolen password.
• The compromise can persist after password changes because refresh tokens often outlive the original login event.
• Defence has to move toward consent governance, connected app review, and token revocation rather than relying on credential-focused controls alone.

Related NHI Mgmt Group resources: OAuth 2.0 and OpenID Connect Guide for Identity Teams · Ultimate Guide to NHIs: What are Non-Human Identities · Passwordless and Passkeys Guide · Identity Attack Statistics Guide

Key terms

• Device Authorization Grant: An OAuth flow that lets a user complete sign-in on a separate browser device while the CLI polls for approval. It is useful when no local browser is available, but the cross-device handoff also creates a phishing pattern that identity teams need to govern carefully.
• SSO Assertion: An SSO Assertion is a signed statement from an identity provider that a user has authenticated and may be trusted by a service provider. It usually carries attributes such as the subject, audience, and authentication time, and is consumed by the application to create a session without prompting for separate credentials.
• OAuth Access Token: A short-lived bearer credential issued after successful authorization that allows an application to call APIs on a user's behalf. In NHI governance terms, it is a reusable access artifact whose scope, expiry, and revocation path must be controlled like any other privileged credential.
• OAuth Refresh Token: An OAuth refresh token is a long-lived credential that lets an application request new access tokens without asking the user to log in again. In practice, it behaves like a reusable access key, so compromise can create persistent access until the token is revoked or expires.

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.