We run an internal self-service platform API, and employees sometimes need to access it from command-line tools or scripts. Right now, we issue a static token, display it once in the UI, and leave the user responsible for storing it. That approach has two major problems: the token can retain access after the user loses an admin role, and copy-pasting encourages secrets to end up in .env files, shell history, or chat messages.
For anyone using per-request authorization, how much latency and directory load did it add? How long did you cache authorization decisions, and did you fail open or fail closed when the identity or role service was unavailable?
Would a short-lived token obtained by exchanging an existing SSO session be the better option for human CLI and scripting access? I'm also considering per-user mTLS certificates, short-expiry personal tokens with strong auditing, or storing credentials in a secret manager. If you went with secret-manager-backed credentials, did rotation happen transparently, or did clients experience outages because they cached old values?
4 Answers
For browser-based SSO from a CLI, we built a small helper that starts a temporary local HTTP listener to receive the authorization callback. A device-code flow can avoid that callback server, although it means the user has to enter a code on another device or browser. Either way, the CLI should obtain short-lived access tokens and refresh them through the identity provider rather than storing a permanent API secret.
The cleanest design is to keep authorization out of the token. Use a short-lived credential that identifies the user, then evaluate the user’s current roles and resource permissions on each request. That way, losing an admin role takes effect quickly instead of leaving an old token with stale authority. For CLI access, an OIDC device-code flow is a good fit because it gives the tool a real SSO-based login without asking users to paste long-lived secrets into configuration files. A small cache—around 30–60 seconds keyed by user and resource—can reduce directory traffic. I’d fail closed if the authorization store is unavailable; a brief denial is safer than accidentally granting access during an outage.
If role changes need to take effect reliably, don’t depend only on group claims issued during login. Keep the authoritative role or account mapping in a directory or policy service and consult it during authorization, possibly with a short cache. OAuth or OIDC with a confidential client is common for service integrations, but human-oriented API identity is harder because there isn’t a universally convenient equivalent of a permanent personal token. A dedicated CLI login flow is generally safer than trying to make a long-lived user secret behave like SSO.
One possible pattern is to use an encrypted, signed token that carries identity and carefully controlled metadata, then have the API validate and augment it with current policy information. That can reduce repeated lookups, but it shouldn’t be used to embed permissions that must be revoked immediately. For long-running jobs, use a separate workload identity with its own short-lived credentials and rotation, rather than extending a human token indefinitely.
How would you handle tools or jobs that need to keep running for a long time?