Notifications
Clear all
Topic starter
06/06/2026 1:45 am
TL;DR: PKCE is the safer default for interactive CLI authentication because it binds the authorization code to the same machine, while device flow remains useful for SSH, containers, and other headless contexts, according to WorkOS. The real decision is whether your enterprise is optimizing for phishing resistance or environment flexibility, and that trade-off belongs in identity governance, not just developer experience.
NHIMG editorial — based on content published by WorkOS: PKCE vs Device Flow: Which OAuth flow is best for CLI auth?
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
What's in the full article
WorkOS's full article covers the operational detail this post intentionally leaves for the source:
- Exact protocol steps for both Authorization Code with PKCE and OAuth 2.0 Device Authorization Grant.
- The decision matrix for laptops, SSH sessions, containers, cloud IDEs, and CI runners.
- Detailed error handling for authorization_pending, slow_down, and expired_token states.
- Implementation notes for building a CLI auth path that works across enterprise tenants.
👉 Read WorkOS's comparison of PKCE and device flow for CLI auth →
PKCE vs device flow for CLI auth: are your controls keeping up?
Explore further
06/06/2026 3:03 am
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.
A few things that frame the scale:
- 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.
- 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.
A question worth separating out:
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.
👉 Read our full editorial: PKCE vs device flow for CLI auth: what security teams should know
