Notifications
Clear all
Topic starter
08/06/2026 4:39 pm
TL;DR: Python CLI tools can authenticate users through the OAuth 2.0 Device Authorization Grant, using a browser-based approval step, periodic polling, and token exchange to avoid manual token pasting, according to WorkOS. The pattern is practical for command-line apps, but it also reinforces how device-code flows shift trust, token handling, and user verification into IAM design choices.
NHIMG editorial — based on content published by WorkOS: How to add auth to your Python CLI using WorkOS Authenticate users in your Python command-line tool with a secure OAuth 2.0 Device Code flow
Questions worth separating out
Q: How should security teams handle browser-based login for Python CLI tools?
A: Security teams should treat browser-based CLI login as a delegated authentication flow, not as a lower-risk shortcut.
Q: Why do device code flows matter for identity governance?
A: Device code flows matter because they separate user verification from token use.
Q: What breaks when a CLI logs or stores access tokens carelessly?
A: Careless token handling turns a clean login flow into a credential exposure problem.
Practitioner guidance
- Define token storage boundaries Store device-flow access tokens in the smallest practical local scope, avoid writing them to logs or shell history, and set explicit expiration and revocation handling for CLI sessions.
- Enforce server-driven polling behaviour Use the interval returned by the authorization response, handle slow_down by backing off, and stop polling cleanly when the code expires or is denied.
- Separate user approval from credential reuse Treat browser consent as authentication, then require a distinct policy for how the CLI stores and reuses the resulting access token for API calls.
What's in the full article
WorkOS' full tutorial covers the implementation detail this post intentionally leaves for the source:
- The exact Python request and polling code needed to call the device authorization and token endpoints.
- The terminal prompt pattern for displaying the user code and verification URL without exposing the device code.
- The sample response fields returned after successful authentication, including token and user metadata.
- The complete step-by-step flow for wiring the login process into a runnable CLI entry point.
👉 Read WorkOS' tutorial on adding OAuth device code login to a Python CLI →
Python CLI device code login: what IAM teams should watch?
Explore further
08/06/2026 6:24 pm
Device-code login is a human IAM pattern that inherits NHI secret-handling risk once the token is issued. The article solves the front-end problem of authenticating a CLI user without an embedded browser, but the security boundary moves immediately after approval. Once the access token exists, the CLI becomes a bearer-token consumer, which means token storage, exposure, and reuse matter as much as the login step. Practitioners should treat the post-authentication token as the real asset, not the browser interaction.
A few things that frame the scale:
- Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
A question worth separating out:
Q: What should teams do after a user completes device-code authentication?
A: Teams should treat the post-authentication token as a governed secret, not as a temporary implementation detail. That means defining where the token is stored, how refresh works, how revocation is triggered, and how the CLI behaves when the token expires. The objective is to keep the credential lifecycle bounded after the browser approval ends.
👉 Read our full editorial: OAuth device code login for Python CLIs and IAM risk
