Notifications
Clear all
Topic starter
06/06/2026 2:12 am
TL;DR: Rust CLI login flows that use OAuth 2.0 device code exchange a browser step for terminal-friendly authentication, but they still create a non-human identity trust boundary around device codes, polling, and token handling, according to WorkOS. The governance question is not whether the flow works, but which NHI controls protect short-lived credentials and prevent token exposure.
NHIMG editorial — based on content published by WorkOS: How to add auth to your Rust CLI using WorkOS
Questions worth separating out
Q: What breaks when device code login is treated like a normal CLI convenience feature?
A: The flow breaks when teams ignore that the CLI is holding a bearer token on behalf of a user.
Q: Why do device code flows still need non-human identity controls?
A: Because the browser authenticates the person, but the CLI receives a machine-held credential that can be reused, exposed, or wrapped by other tooling.
Q: How do teams know if CLI authentication is leaking credentials?
A: Look for tokens in logs, shell history, crash reports, telemetry, and pasted support transcripts.
Practitioner guidance
- Classify CLI device codes as short-lived NHI credentials Track the device code, verification URL, and returned tokens as sensitive authentication artefacts with explicit handling rules.
- Bound token polling with explicit stop conditions Respect the returned interval, stop on access_denied or expired_token, and add a hard timeout so polling cannot continue after the approval window closes.
- Keep access tokens out of terminal output Use redacted secret types, avoid printing raw tokens, and expose secrets only when a downstream API call genuinely needs them.
What's in the full article
WorkOS's full tutorial covers the operational detail this post intentionally leaves for the source:
- Complete Rust code for the device authorization request, polling loop, and main function wiring.
- Cargo dependency list and SDK setup details for a working CLI implementation.
- Browser-opening behaviour and cross-platform handling for the verification URL.
- Token response handling examples, including the SDK's secret redaction behaviour.
👉 Read WorkOS's tutorial on adding OAuth device code auth to a Rust CLI →
Rust CLI device code auth: what IAM teams need to watch?
Explore further
06/06/2026 3:44 am
Device code authentication is an NHI delegation pattern, not just a convenience flow. The browser approves the human, but the CLI becomes the non-human identity that holds and uses the resulting access token. That means the relevant governance problem is delegation scope, token lifetime, and where the secret can be observed after approval. Practitioners should treat this as a machine-held credential with a user-granted origin, not as a human login flow that happens to start in a terminal.
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.
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which shows how quickly delegated access paths outgrow human review models.
A question worth separating out:
Q: Who is accountable when a CLI-issued access token is exposed?
A: Accountability sits with the team that designed and operated the login flow, because the browser approval does not end their responsibility for the issued secret. Governance, logging, retention, and downstream reuse all determine whether the token remains a controlled credential or becomes an uncontrolled NHI artefact.
👉 Read our full editorial: Rust CLI device code auth exposes the new NHI trust boundary
