Topic starter
12/06/2026 9:18 pm
TL;DR: CLI authentication to enterprise SSO works best when teams choose between OAuth Device Code and PKCE based on runtime context, not convenience, according to WorkOS. The broader lesson is that headless and local environments need different identity patterns, and refresh-token storage becomes the control point that matters most.
Editorial analysis by NHI Mgmt Group, based on content published by WorkOS: “How to add enterprise SSO to your CLI”.
Key questions
Q: How should security teams choose between Device Code and PKCE for CLI sign-in?
A: Use PKCE when the user has a local browser and the CLI can bind to a loopback redirect.
Q: Why is Device Code more exposed to phishing than PKCE?
A: Device Code asks the user to type a code into a browser session, so an attacker can try to trick the user into entering a valid code after starting a parallel flow.
Q: What breaks when CLI authentication relies on static API keys instead of SSO?
A: Static API keys do not inherit the organisation’s browser-based identity controls, so they bypass MFA, conditional access, and federated login policies.
Practitioner guidance
- Default to PKCE for interactive CLI logins Use Authorization Code with PKCE when the user has a local browser and the CLI can bind a loopback callback on the same machine.
- Reserve Device Code for headless paths Use Device Code only for SSH sessions, containers, remote dev boxes, or other environments where a local browser callback is not realistic.
- Store refresh tokens as the primary credential Treat the refresh token as the long-lived asset and store it with the strongest mechanism your runtime can support, such as a permission-restricted file or an OS keychain.
Bottom line: CLI SSO is an identity design choice, not a code-snippet problem, because the authentication flow must fit the runtime the tool actually runs in.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
12/06/2026 11:17 pm
CLI authentication is now part of enterprise identity governance, not a side channel. When a terminal tool can authenticate through the same IdP policies as a web app, it inherits the same access control expectations and the same governance obligations. That means identity teams need to treat CLI sign-in patterns as first-class access paths, not developer convenience features. The programme implication is that terminal access belongs in the same policy conversation as browser-based SSO.
A few things that frame the scale:
- Across one million observed logins, 1 in 4 were password-based rather than SSO, 2 in 5 were not protected by MFA and 1 in 5 used a weak, breached or reused password.
A question worth separating out:
Q: How should security teams govern refresh tokens in CLI tools?
A: Treat refresh tokens as the durable credential in the session lifecycle, store them with local protections that match the runtime, and replace them whenever rotation returns a new value. If the CLI supports multiple organisations, keep token state separated by tenant so one session cannot spill into another.
👉 Read our full editorial: Enterprise SSO for CLIs depends on the right OAuth flow