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.
Editorial analysis by NHI Mgmt Group, based on content published by WorkOS: “PKCE vs Device Flow: Which OAuth flow is best for CLI auth?”.
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.
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 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.
Practitioner guidance
- 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.
Bottom line: PKCE gives interactive CLI sign-in a stronger machine binding, while device flow trades that binding for cross-device flexibility.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 8 hours ago by NHI Mgmt Group
06/06/2026 3:03 am
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.
A few things that frame the scale:
- Security researchers tracked consent phishing campaigns affecting 900 tenants and 3,000 user accounts in 2025.
A question worth separating out:
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.
👉 Read our full editorial: PKCE vs device flow for CLI auth: what security teams should know
This post was modified 8 hours ago by NHI Mgmt Group