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

At a glance

What this is: This is a security-first comparison of PKCE and OAuth device flow for CLI authentication, with a clear recommendation to default to PKCE for local interactive use.

Why it matters: It matters because CLI authentication is now part of identity governance for workloads and developers, and the wrong flow choice can create avoidable phishing exposure or break enterprise tenant compatibility.

By the numbers:

• AWS CLI v2.22+ switched the default for aws sso login from device code to PKCE and put device code behind a --use-device-code flag.

👉 Read WorkOS's comparison of PKCE and device flow for CLI auth

Context

PKCE versus device flow is an identity governance decision, not just an implementation choice. Both patterns delegate sign-in to a browser, but they assume very different runtime conditions, which changes the security profile for CLI authentication, SSO, MFA, and conditional access.

For IAM teams, the key issue is where trust is anchored. PKCE binds the authorization code to the local machine through a loopback redirect, while device flow decouples the browser session from the CLI entirely. That makes device flow practical for headless environments, but it also creates a phishing surface that enterprise controls do not always detect.

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 do teams get wrong about browser-based CLI authentication?

A: They often assume that any OAuth flow using a browser is equally safe. In practice, the security boundary depends on whether the authorization result is machine-bound or transferable. PKCE is tied to the local execution context, while device flow is intentionally decoupled, which makes it easier to misuse in enterprise environments.

Q: When should organisations avoid device flow entirely?

A: Avoid it when the CLI is used on managed endpoints that already support a local browser, or when tenant policy may block the flow. In those cases, device flow adds risk without adding necessary capability. For CI and fully automated jobs, skip both browser-delegated flows and use workload identity instead.

Technical breakdown

How PKCE binds CLI authentication to the local machine

Authorization Code with PKCE uses a random code_verifier and a derived code_challenge to protect the token exchange. The CLI starts a loopback HTTP listener on 127.0.0.1, opens the user’s browser, and receives the authorization code on the same host that initiated the request. That design means the code is never meant to be transcribed by a person, which removes the device transfer step that creates interception risk in other flows. The security property comes from locality plus cryptographic binding, not from the browser itself.

Practical implication: treat PKCE as the default for interactive CLIs on user-owned endpoints.

Why device flow creates a different phishing model

OAuth 2.0 Device Authorization Grant intentionally splits the browser session from the CLI session. The CLI requests a device_code and user_code, then polls the token endpoint until the user approves in a browser on any device. That flexibility is the feature, but it also means the user code acts like a bearer credential for the polling session. An attacker can initiate the legitimate flow, trick a victim into entering the code, and receive the resulting tokens without ever compromising the IdP screens or MFA controls.

Practical implication: reserve device flow for contexts where no local browser or loopback redirect is available.

Where enterprise policy changes the CLI decision

Conditional access can now determine whether a CLI flow is even allowed. Some tenants block device flow outright, which means a device-code-only CLI will fail before the user finishes sign-in. That shifts the architectural decision from convenience to compatibility: if a CLI targets enterprise customers, the authentication path must survive tenant policy variation. Mature deployments therefore ship both flows, default to PKCE, and keep device flow as an explicit fallback rather than the primary path.

Practical implication: design CLI auth so tenant-level policy changes do not strand the product.

Threat narrative

Attacker objective: The attacker’s objective is to obtain valid OAuth tokens for a victim account by abusing the device flow trust model.

1. Entry occurs when an attacker starts a legitimate device authorization session and obtains a real device_code and user_code from the identity provider.
2. Credential access occurs when the attacker convinces a victim to enter that code into the real verification URL, causing the IdP to issue tokens for the attacker’s polling session.
3. Impact occurs when the attacker receives valid OAuth tokens and can act as the authenticated user without defeating the browser, MFA, or IdP branding.

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

PKCE is the safer CLI baseline because it preserves a machine-bound trust model. The browser still handles SSO and MFA, but the authorization code returns to the same host that initiated the flow. That keeps the identity event tied to a specific local execution context, which is a better fit for enterprise control boundaries than a transferable user code. For IAM teams, the lesson is that CLI authentication should be treated like any other workload identity path: locality and binding matter.

Device flow exposes a named failure mode we can call the cross-device approval gap. The flow was designed for input-constrained devices, not as a general-purpose enterprise default. Once the user code becomes portable across devices, the approval step is no longer bound to the original workload, and that weakens the governance assumption that the approving user is also the same context that initiated the request. Practitioners should recognise this as a control-plane gap, not just a usability trade-off.

Conditional access policy is now part of CLI authentication design. The article shows that some tenants already block device flow entirely, which means identity policy can override application convenience. That shifts responsibility onto architects to ensure the CLI can negotiate enterprise policy without breaking core workflows. The implication is simple: if a CLI must work in regulated or centrally managed environments, the auth model must survive tenant policy variance.

Least privilege for CLIs is not just about scopes, but about the initiation context. PKCE narrows the opportunity for token interception because the code is delivered over a local loopback channel and tied to a verifier the CLI generated. Device flow, by contrast, separates initiation from approval and makes the handoff itself the risk boundary. That means governance should evaluate not only what the CLI can do after login, but how the login event itself can be hijacked.

Runtime governance for CLI auth should prefer flow choice over downstream compensating controls. The strongest signal in this comparison is that different operating contexts require different authentication bindings. Laptops, workstations, and other interactive endpoints fit PKCE; headless servers and containers may need device flow; CI should use workload identity instead of either browser-delegated pattern. Teams should make that decision explicitly rather than allowing every CLI to inherit the weakest viable default.

From our research:

• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• From our research: Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, according to The State of Non-Human Identity Security.
• Forward pivot: If your organisation is already tightening NHI governance, start with Analysis of Claude Code Security to see how browser-delegated identity patterns expand into AI-assisted developer workflows.

What this signals

Cross-device approval is the named concept here. When a browser approval step can be completed on any device, the governance model no longer knows whether the approving context matches the initiating context. That matters for developer tooling because the authentication event can succeed while the original CLI session remains attacker-controlled. Teams should map every browser-delegated flow to the exact execution environments where it is genuinely safe to use.

The policy signal is that identity teams should stop treating CLI auth as a single pattern. PKCE, device flow, and workload identity belong to different operating modes, and enterprise control planes are already discriminating between them through conditional access and tenant policy. For reader programmes, that means auth design, endpoint posture, and workload identity need to be reviewed together rather than as separate projects.

With 1 in 4 organisations already investing in dedicated NHI security capabilities, the market is moving toward tighter control of non-human sign-in paths, not looser convenience defaults, per The State of Non-Human Identity Security. Browser-delegated CLI auth is part of that same governance surface, especially once developers and automation share the same identity infrastructure.

For practitioners

• Default interactive CLIs to PKCE Use Authorization Code with PKCE for user-owned laptops and workstations, and keep the loopback redirect bound to 127.0.0.1 with a dynamic port.
• Gate device flow behind an explicit fallback Expose device code only with an intentional flag or alternate path, and restrict it to SSH sessions, containers, cloud IDEs, and other headless environments.
• Align CLI auth with tenant policy Test your CLI against tenants that block the device code flow, and ensure the product still authenticates cleanly when conditional access disables that path.
• Use workload identity for CI and non-human execution Do not force either browser-delegated OAuth flow into CI runners or fully automated jobs. Use workload identity or client credentials for non-interactive execution.

Key takeaways

• PKCE is the better default for interactive CLI authentication because it binds the authorization code to the same machine that initiated the flow.
• Device flow remains useful for headless environments, but its cross-device approval model creates a phishing surface that enterprise policy is increasingly willing to block.
• Identity teams should govern CLI authentication by execution context, not by developer convenience, and use workload identity for fully automated execution.

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 Approval Gap: A failure mode where a user approves a login from a different device than the one that initiated the request. In CLI authentication, this breaks the assumption that approval and execution share the same trust boundary, making the resulting token easier to abuse.

Deepen your knowledge

PKCE versus device flow for CLI authentication is covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are deciding how to govern developer and workload sign-in paths, it is a useful place to start.

This post draws on content published by WorkOS: PKCE vs Device Flow: Which OAuth flow is best for CLI auth? Read the original.