Notifications
Clear all
Topic starter
08/06/2026 4:38 pm
TL;DR: A Go CLI login pattern built on the OAuth 2.0 Device Authorization Grant lets the tool request a device code, have the user approve in a browser, and poll for tokens instead of collecting pasted credentials, according to WorkOS. The pattern reduces token handling friction, but it also shifts identity trust, polling discipline, and lifecycle control into the CLI runtime.
NHIMG editorial — based on content published by WorkOS: How to add auth to your Go CLI using WorkOS
Questions worth separating out
A: Use the OAuth 2.0 Device Authorization Grant so the human signs in through a browser while the CLI only requests and exchanges a device code.
Q: Why do CLI authentication flows need the same governance as other non-human identities?
A: Because the CLI is the entity that receives, stores, and reuses tokens after the human authenticates.
Q: What breaks when a CLI prints or logs access tokens after browser sign-in?
A: The authentication ceremony may succeed, but the resulting credential can be copied into logs, shell history, crash dumps, or telemetry.
Practitioner guidance
- Register CLI tools as public clients only Treat the terminal app as a public OAuth client and avoid any design that depends on protecting a client secret inside the executable.
- Bound the polling loop and honour expiry signals Use the authorization server interval, increase backoff on slow_down responses, and stop polling on access_denied or expired_token.
- Handle returned tokens as secrets Do not print access tokens or refresh tokens to the terminal, logs, telemetry, or crash reports.
What's in the full article
WorkOS's full tutorial covers the implementation detail this post intentionally leaves at the governance layer:
- Go code for requesting the device code and user code from the authorization endpoint
- Polling logic that handles authorization_pending, slow_down, access_denied, and expired_token responses
- Step-by-step terminal output handling for user_code and verification_uri_complete
- A complete working main function that ties the device flow together
👉 Read WorkOS's tutorial on adding OAuth device flow to a Go CLI →
Go CLI auth with device flow: what IAM teams should watch?
Explore further
08/06/2026 6:22 pm
CLI login flows expose a governance blind spot when teams treat a terminal app like a disposable utility instead of an identity-bound client. The device code pattern pushes human authentication into the browser, but the CLI still becomes the recipient of tokens and the operator of the polling loop. That makes the CLI a governed identity surface, not just a user interface. Practitioners should classify the client, the token lifetime, and the storage path before they classify the feature as 'just authentication.'
A few things that frame the scale:
- 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to The State of Non-Human Identity Security.
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, showing that delegated access remains a governance blind spot.
A question worth separating out:
Q: How can organisations decide whether device flow is appropriate for a CLI application?
A: Use it when the tool cannot safely embed a browser and the user experience would otherwise require pasted credentials. It is appropriate only if the app is registered correctly, token lifetime is bounded, and revocation is defined. If the CLI needs long-lived, high-privilege access, treat it as a governed client and reconsider the architecture.
👉 Read our full editorial: OAuth device flow in Go CLIs shifts auth out of the terminal
