We run an internal self-service platform API, and people need to access it from CLI tools and scripts. Right now, we create a static token, display it once in the UI, and leave the user responsible for storing it. That approach has a couple of problems: the token can retain access to accounts after the user loses the corresponding admin role, and users often end up copying the secret into .env files, shell history, or chat messages.
I'm considering short-lived, identity-only tokens with authorization checked against the current role or directory state on each request. If you've implemented that, how much latency and directory load did it add? How long did you cache authorization decisions, and did you fail closed or open when the identity provider was unavailable?
For interactive users, has anyone successfully used an SSO-based flow—such as an OAuth/OIDC device authorization flow or a CLI that receives a browser callback—to obtain short-lived credentials? Is there a simpler approach, such as per-user mTLS certificates, short-expiry personal tokens, or a secret manager? If you use a secret manager, does rotation work transparently, or do clients that cache credentials still cause outages?
5 Answers
Secret-manager rotation only works invisibly if clients retrieve credentials dynamically and do not cache them beyond the rotation window. Otherwise, rotation can create outages when a process keeps using the old value. For user-facing CLI access, an SSO exchange is usually preferable to rotating personal secrets. For services, use secret-manager-backed workload credentials or a token broker, test rotation regularly, and make clients retry cleanly when a credential is rejected.
A browser-based CLI flow can work well: the tool starts a temporary local callback server, the user signs in through the normal SSO page, and the CLI stores only a short-lived access token or refresh token in the operating system’s credential store. A device-code flow is another option, especially on headless machines, although it requires the user to enter a code on another device. Either approach is safer than displaying a personal access token once and expecting users to protect it manually.
Putting current permissions directly into a signed token can reduce directory traffic, but it does not solve immediate revocation unless the token is very short-lived or you maintain a revocation/version check. Claims can become stale when group membership changes. A better compromise is to keep the token small, use a short lifetime, and combine it with a cached authorization lookup or an account policy version that changes whenever access is revoked.
For long-running automation, separate it from human credentials. Use a workload identity or service account with narrowly scoped permissions, short-lived credentials, and an automated renewal or exchange mechanism. The job should obtain a fresh token when needed rather than keeping one permanent secret. If a human must remain accountable for the action, record the initiating user separately and enforce an explicit ownership or delegation policy.
The cleanest model is to keep authorization out of the credential. Issue a short-lived token that identifies the user, then make the authorization decision from the current role and resource state on each request. That way, losing an admin role takes effect quickly instead of leaving an old token with permanent authority.
For human CLI access, an OAuth/OIDC device flow is a good fit because the user authenticates through SSO without copying a long-lived secret into configuration files. A small CLI can also open a temporary local HTTP listener to receive the browser callback. Cache authorization decisions briefly—around 30 to 60 seconds is a reasonable starting point—and fail closed if the authorization store cannot be reached. A temporary denial is safer than granting access during an identity-system outage.
How would you handle jobs or scripts that need to run for much longer than the token lifetime?