PKCE vs device flow for CLI auth: what security teams should know

At a glance

What this is: NHI Mgmt Group's analysis, drawing on WorkOS's blog post: PKCE and device flow are compared for CLI authentication, and PKCE is the safer default for interactive local use while device flow fits headless and cross-device scenarios.

Why it matters: IAM teams and platform owners need to align CLI auth choices with environment constraints, phishing resistance, and enterprise conditional access rather than treating both OAuth flows as interchangeable.

Context

CLI authentication is really an identity design decision about where trust lives. For interactive users on a laptop, the browser can stay bound to the same machine through a loopback redirect, but headless environments such as SSH sessions, containers, and cloud IDEs break that assumption and force a different model.

PKCE and device flow both delegate sign-in to a browser and both end in tokens, but they make different assumptions about the local environment and the degree of binding between the device that starts authentication and the device that completes it. That difference changes phishing resistance, tenant compatibility, and how identity governance should treat CLI access.

For identity teams, the practical question is whether the CLI is operating as a user-facing client on a trusted endpoint or as a workflow component in an environment without a usable browser. The right answer changes the security control choice, the rollout policy, and the exception handling model.

Key questions

Q: How should security teams choose between PKCE and device flow for CLIs?

A: Use PKCE for interactive users on their own machines, because it binds the authorization code to the local host and reduces phishing exposure. Use device flow only when no local browser or loopback redirect is practical, such as SSH sessions or containers. If the CLI targets enterprise tenants, ship both and default to the safer path.

Q: Why does device flow create more authentication risk than PKCE?

A: Device flow separates the browser session from the CLI session, so the user code can be reused across devices. That portability is useful, but it also enables phishing attacks where the victim approves a real IdP prompt for an attacker-controlled polling session. PKCE avoids that specific gap by keeping the code bound to the originating machine.

Q: What are the signs that device flow is the wrong default for a CLI?

A: Device flow is the wrong default when users have a local browser, when the environment can bind a loopback port, or when enterprise tenants may block the flow with conditional access. If the same application is mostly used on laptops or workstations, device flow should look like an exception, not the baseline.

Q: When should organisations use workload identity instead of user-based CLI auth?

A: Use workload identity when no human should be in the loop, such as CI runners, automation jobs, or service-to-service tasks. In those cases, neither PKCE nor device flow is the right pattern because the objective is not interactive user authentication. Workload identity avoids forcing a browser-mediated flow onto a non-interactive workload.

Technical breakdown

How PKCE binds the authorization code to one machine

Authorization Code with PKCE adds a cryptographic proof to the OAuth authorization code exchange. The CLI creates a random code_verifier, derives a code_challenge, and starts a local HTTP listener on 127.0.0.1 so the browser can return the authorization code to the same machine. That loopback binding matters because the code is only useful together with the original verifier, which never leaves the CLI process. In practice, PKCE narrows the attack surface to local process and browser compromise rather than allowing a separate device to redeem the code. This is why PKCE is the better fit when the user and CLI share one endpoint.

Practical implication: Prefer PKCE for interactive CLIs on managed endpoints and treat loopback redirect support as a required control, not a convenience.

Why device flow decouples the browser from the CLI session

The OAuth 2.0 Device Authorization Grant separates the CLI session from the browser session. The CLI requests a device_code and user_code, the user completes sign-in on any browser-capable device, and the CLI polls the token endpoint until approval arrives. That design is useful when the CLI cannot host a browser or receive a loopback callback, which is common in SSH sessions, containers, and embedded or remote environments. The trade-off is that the approval process is no longer bound to the machine that initiated it, so the user code functions more like a shared claim token than a machine-bound credential. That flexibility is the feature and the risk.

Practical implication: Use device flow only when the runtime cannot support a same-device browser callback or when cross-device sign-in is an explicit requirement.

Where the phishing risk in device flow comes from

Device flow creates a known phishing pattern because the user can be tricked into entering a legitimate code into a legitimate site for an attacker-controlled polling session. The identity provider sees a real sign-in, real MFA, and a real token issuance, so many traditional phishing signals do not fire. That is why enterprise tenants increasingly block the flow for some users or applications and why CLI vendors are moving to PKCE-first defaults. The important mechanism is not weak authentication, but decoupled approval: the browser session authenticates the person, while the polling client quietly receives the token. That split is what attackers exploit.

Practical implication: Treat device flow as a deliberate exception path and require explicit policy review before allowing it in higher-risk enterprise tenants.

Threat narrative

Attacker objective: The attacker wants to convert a legitimate OAuth approval into tokens under an attacker-controlled polling session and use that access as if the user approved it directly.

1. Entry occurs when an attacker obtains or brokers a legitimate device_code and user_code pair from the OAuth device authorization endpoint or a real CLI session.
2. Credential harvesting happens when the victim is socially engineered into completing sign-in and entering the code into the legitimate verification site.
3. Escalation follows when the attacker, already polling the token endpoint, receives access tokens tied to the approved device code session.
4. Impact is unauthorized access to the target identity context without alerting the IdP to an obviously suspicious browser or MFA event.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
• Taiwan autonomous AI agent cyberattack 2026: Up to eight autonomous AI agents cracked 85 Taiwanese government accounts, pivoted through SSO and exfiltrated 2,564+ personnel records.

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

Device flow exposes a binding failure, not just a weaker login path. The control assumption behind browser-delegated CLI auth is that the approval event remains tied to the originating machine long enough to be trusted. Device flow breaks that binding by design, which means the approval and the token recipient can be different endpoints. Practitioners should treat that as a governance boundary, not a minor UX trade-off.

PKCE is the better fit when the identity decision and the execution environment are the same machine. The loopback redirect and code_verifier restore a machine-bound trust relationship that aligns with managed laptop use and enterprise desktop sign-in. That makes PKCE a cleaner default for interactive CLI authentication because it preserves the locality assumption that most access review and endpoint trust models still rely on.

Device flow should be governed as an exception path for headless contexts. SSH, containers, cloud IDEs, and embedded environments do not support the same trust binding as a local browser callback, so device flow solves a real operational problem. The issue is not existence of the flow, but unmanaged sprawl of where it is allowed. Identity teams should classify device-flow use as a constrained operating mode, not a universal fallback.

PKCE vs device flow is really a question of phishing resistance versus environment flexibility. That is the right abstraction for IAM and platform teams because it maps directly to policy, tenant configuration, and application defaults. The practical conclusion is to make the secure, machine-bound flow the default and reserve the cross-device flow for documented exceptions.

OAuth trust in CLI auth should be expressed as environment policy, not developer preference. When teams let every CLI choose its own auth pattern, they push identity risk into application code. The better model is to define which environments may use loopback-bound PKCE, which may use device flow, and where conditional access should block the latter.

From our research library:

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

What this signals

Machine-bound authentication is the governing concept here. Once a CLI can complete OAuth on the same endpoint that started the request, PKCE preserves the trust boundary that many enterprise access models assume. When that boundary does not exist, device flow becomes an exception mechanism rather than a default.

CLI auth design is increasingly an identity governance problem, not just a protocol choice. Teams need policy clarity on which environments may use a loopback redirect, which may use a cross-device grant, and which should move to workload identity instead of user delegated sign-in.

For practitioners

• Default interactive CLIs to PKCE Make Authorization Code with PKCE the default for users on their own managed machines, and require the browser callback to stay loopback-bound on the same endpoint.
• Restrict device flow to documented headless cases Allow the Device Authorization Grant only for SSH, containers, cloud IDEs, and other environments that cannot support a local browser callback.
• Treat device code as an exception path Put an explicit flag or policy gate in front of device flow so the safer local-machine path remains the normal choice for CLI sign-in.
• Align conditional access with CLI auth mode Block or limit device-flow grants for higher-risk users, applications, or tenants where the approval session can be separated from the CLI session.
• Document which environments can use each flow Publish a simple mapping that states when PKCE is permitted, when device flow is permitted, and when neither should be used because workload identity is the better fit.

Key takeaways

• PKCE gives interactive CLI sign-in a stronger machine binding, while device flow trades that binding for cross-device flexibility.
• The main security difference is not token format, but whether the approval event stays tied to the same endpoint that initiated the request.
• Enterprises should treat device flow as a constrained exception and use policy, tenant controls, and workload identity to reduce unnecessary exposure.

Key terms

• Authorization Code With PKCE: An OAuth flow that protects the authorization code with a code verifier and challenge pair. For CLIs, it usually relies on a loopback redirect to bind the sign-in result to the same machine that started the login, which reduces code interception risk.
• 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.
• Loopback Redirect: A local callback path, usually on 127.0.0.1, used by native apps and CLIs to receive an OAuth authorization code from a browser. It keeps the token exchange tied to the originating machine, which is why it is a core security property of PKCE-based CLI authentication.
• Cross-Device Authentication: An authentication pattern that begins on one device and completes on another, often with a trusted phone approving a session started elsewhere. It reduces password exposure on shared or keyboard-limited devices and is especially useful for retail checkout and kiosk scenarios.

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.