Rust CLI device code auth exposes the new NHI trust boundary

At a glance

What this is: This is a Rust CLI authentication tutorial that shows how device code OAuth creates a terminal-friendly login flow while shifting the security burden onto NHI credential handling and polling discipline.

Why it matters: It matters because IAM teams must govern ephemeral machine-mediated authentication paths with the same rigor they apply to service accounts, tokens, and other non-human identities.

👉 Read WorkOS's tutorial on adding OAuth device code auth to a Rust CLI

Context

Rust CLI authentication is the practice of letting a command-line application obtain user approval through a browser-mediated OAuth flow instead of collecting passwords or pasted tokens. In this tutorial, the primary governance issue is not the Rust implementation itself, but how a device code flow creates a temporary non-human identity path that still needs lifecycle control, token hygiene, and clear user accountability.

Device code flows are attractive for terminal tools because they avoid embedded browsers and manual token handling, but they also create a new boundary between the CLI, the browser session, and the resulting access token. For IAM teams, that boundary should be treated as an NHI trust path, not a convenience feature, because the security of the workflow depends on how the device code, polling cadence, and token exposure are constrained.

Key questions

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. If the device code, access token, or refresh token is printed, logged, or copied into scripts, the login becomes a secret distribution path instead of a controlled authentication flow. That is an NHI governance problem, not just an implementation detail.

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. Non-human identity controls matter here because the operational risk sits in token lifetime, storage, and propagation, not in the act of user sign-in itself.

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. Also watch for unusually long-lived refresh tokens and scripts that reuse a token after the original login session should have ended. Those are signs that the authentication flow has escaped its intended boundary.

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.

Technical breakdown

Device code flow in a Rust CLI

The OAuth 2.0 Device Authorization Grant is designed for input-constrained clients such as CLIs. The application first requests a device_code and user_code, then sends the user to a verification URL where they complete authentication in a browser. The CLI never handles interactive login itself. Instead, it becomes a polling client that waits for authorization to complete and then receives tokens. This pattern reduces password handling, but it shifts trust into the lifecycle of the device code and the secure treatment of the returned token set. In identity terms, the CLI is a non-human actor that is being delegated access through a user-mediated approval step.

Practical implication: Treat the device code as a short-lived NHI credential and restrict where it can be displayed, logged, or stored.

Polling, expiry, and error handling

Polling is the control plane of the device code flow. The client checks the token endpoint at the interval returned by the authorization response, stops when the code expires, and must handle slow_down, access_denied, and expired_token outcomes explicitly. That means the security posture depends on bounded retry logic and clean termination states, not just successful login. A CLI that polls too aggressively can create avoidable noise, while one that ignores expiry can continue to exercise a dead credential path. The important design point is that the access request is time-bound and stateful, even though the application is not a browser-based identity client.

Practical implication: Enforce explicit timeout and stop conditions so token polling cannot drift beyond the approved authorization window.

Token exposure in terminal applications

Once the device flow succeeds, the CLI receives an access token and sometimes a refresh token. Those artifacts are secrets, which means terminal output, debug logs, crash reports, shell history, and telemetry all become possible leakage paths. The tutorial’s use of a redacted secret type is a useful pattern because it limits accidental disclosure, but the deeper issue is that CLI auth turns interactive user consent into a machine-held credential. In other words, the browser authenticates the person, but the CLI governs the secret that continues the session. That separation is where NHI governance starts.

Practical implication: Keep access tokens out of standard output, debug traces, and exception paths, and route them only into controlled secret handling.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Short-lived does not mean low-risk when the secret is terminal-visible. The device code, verification URL, and access token each create separate leakage points if they are printed, logged, or copied into support artefacts. The failure mode is not weak authentication alone, but credential exposure through the operational path around the login flow. In NHI terms, the control boundary is the console, the logs, and the storage layer, which means terminal auth must be governed like any other secret-bearing workload.

Zero standing privilege thinking still applies to CLI auth, but the scope is session-based rather than role-based. A CLI should only hold the access it needs for the task at hand, and that access should expire cleanly when the task ends. The key governance question is whether the token outlives the user interaction in ways the operator cannot see. For IAM programmes, that makes CLI auth part of the same entitlement discipline used for service accounts and other non-human identities.

Token redaction is a baseline control, not a complete control. Hiding secrets in debug output reduces accidental disclosure, but it does not address clipboard transfer, shell persistence, or token reuse in downstream scripts. The governance model has to assume that terminal tooling will be wrapped, scripted, and automated by users. Practitioners should therefore classify CLI-issued tokens as operational secrets and govern them with the same care as other NHI credentials.

Named concept: terminal-held token drift. Once a CLI receives an access token, that token can drift away from the original login context through logs, wrappers, and downstream automation. The concept matters because the security event is no longer the browser approval, but the afterlife of the token in the operator’s environment. Teams should read this as a lifecycle problem for machine-issued credentials, not a front-end authentication problem.

From our research:

• 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.
• That visibility gap matters for terminal auth too, which is why practitioners should also examine Analysis of Claude Code Security for adjacent agentic and CLI identity patterns.

What this signals

Terminal auth is becoming a governance surface, not a developer convenience. As more tools move user approval into browser-mediated device flows, IAM programmes need to decide whether CLI-issued tokens are managed as consumer-style session artefacts or as governed NHI credentials. The distinction matters because logs, wrappers, and local automation can extend token life far beyond the login moment.

Terminal-held token drift: once a CLI receives a bearer token, the identity risk shifts from authentication to propagation. That means the programme needs visibility into where tokens are stored, how they are reused, and which workflows can expose them outside the intended session boundary.

The policy signal is clear: device flows should be evaluated with the same discipline used for other non-human identities, including secret redaction, bounded lifetime, and downstream usage review. Teams that already struggle with OAuth-connected visibility should assume CLI auth will add another unmanaged access path unless they instrument it deliberately.

For practitioners

• 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. Do not let them pass through debug logging, shell history, or support bundles.
• 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.
• Review downstream script handling for token reuse Audit wrapper scripts, CI jobs, and local automation that might capture a successful CLI token and reuse it outside the intended session boundary.

Key takeaways

• Rust CLI device code login is an NHI delegation pattern, because the browser approves the human while the CLI holds the secret.
• The main risk is not the login prompt itself but the token lifecycle, since logs, shells, and wrapper scripts can expose a bearer credential.
• Teams should govern CLI auth with the same controls used for other non-human identities: bounded polling, secret redaction, and downstream reuse review.

Key terms

• Device Code Flow: A device code flow is an OAuth pattern for clients that cannot host a browser. The application gets a user code and polling credential, while the user completes login in a separate browser session. In CLI contexts, it shifts risk into token handling and session boundary control.
• Bearer Token: A bearer token is a secret that grants access to an API or service to whoever presents it. In a CLI workflow, it must be treated as an operational secret because logs, shell history, scripts, and telemetry can all turn a temporary login result into a reusable credential.
• Non-Human Identity: A non-human identity is any machine- or workload-based identity used to access systems, data, or APIs. In CLI auth, the issued token behaves like an NHI credential because it is held and used by software, even though the approval came from a human user.

Deepen your knowledge

Rust CLI device code authentication and terminal-held token governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are extending browser-mediated login into developer tooling, it is worth exploring.

This post draws on content published by WorkOS: How to add auth to your Rust CLI using WorkOS. Read the original.