Skip to content

CONCEPT Cited by 3 sources

Short-lived credential auth

Short-lived credential auth is the security property that a workload's authorization is carried by credentials with minutes- scale lifetime, generated dynamically per session, never stored in configuration or environment variables, and self-rotating. Compromising one credential yields a time-bounded window during which an attacker can act; the window closes automatically without human or automated action.

Canonical quote:

AWS STS credentials are short-lived. Because they're generated dynamically, rather than stored in a configuration file or environment variable, they're already a little bit annoying for an attacker to recover. But they're also dead in minutes. They have a sharply limited blast radius. They rotate themselves, and fail closed. (Source: sources/2024-06-19-flyio-aws-without-access-keys)

The four properties

  1. Dynamic generation. Credentials are minted per session by a token-exchange service (AWS STS, GCP Workload Identity Federation, etc.) rather than written to disk or environment variables at provisioning time.
  2. Short lifetime. Minutes-scale by default (AWS STS default 1 hour, DurationSeconds minimum 15 minutes). Compromise window is bounded by the lifetime.
  3. Self-rotating. The SDK or credential broker re-invokes the mint when approaching expiry; no operator intervention required.
  4. Fail closed. If the mint is unreachable, new requests fail rather than falling back to a cached long-lived credential. The system refuses to do unauthenticated work.

Why this is structurally different from "rotate keys often"

Rotation discipline on long-lived keys is a process property: someone has to remember, someone has to update the secret store, someone has to catch the keys that never got rotated. The failure mode is the old key that never expired.

Short-lived credential auth makes the failure mode impossible by construction: there is no long-lived credential to forget. The credential cannot be older than its lifetime, because it is issued against the current moment.

Blast radius

Short-lived credential auth is a direct blast-radius control. A compromised STS credential can only be used for (say) 15 minutes, and only within the scope of the Role it represents. The same compromise on a long-lived AWS access key grants the attacker open-ended access until the key is rotated — which, if the compromise wasn't detected, means indefinitely.

What stays long-lived

The trust relationship in the cloud provider (IAM Identity Provider + Role + trust policy) is long-lived. The IdP's signing keys are long-lived (rotated out-of-band by the platform). The workload's credentials are short-lived.

This is the same shift as TLS certificates vs session keys: long- lived signing certificates authenticate a one-off short-lived key exchange.

Canonical instance

sources/2024-06-19-flyio-aws-without-access-keys — Fly Machines → OIDC token → AssumeRoleWithWebIdentity → STS credential. The STS credential is the short-lived credential; the OIDC IdP trust + IAM Role are the long-lived substrate.

Contrast: long-lived cloud access keys

Fly.io's opening pitch for why short-lived credential auth matters:

You could ask your security team to create a user, give it permissions, and hand over the AWS keypair. Then you could wash your neck and wait for the blade. Passing around AWS keypairs is the beginning of every horror story told about cloud security, and security team ain't having it. (Source: sources/2024-06-19-flyio-aws-without-access-keys)

The horror stories are pretty consistent in their shape: key committed to a public repo, key logged into an error tracker, key in an environment-variable dump, key that no one knew who owned. All of those vanish as a category when there's no long-lived key to leak.

Relationship to other concepts

Seen in

  • sources/2024-06-19-flyio-aws-without-access-keys — "dead in minutes […] sharply limited blast radius […] rotate themselves, and fail closed"; the STS credential flow via AssumeRoleWithWebIdentity.
  • sources/2025-10-28-redpanda-governed-autonomy-the-path-to-enterprise-agentic-ai — canonical substrate under AAC's "Agents never hold long-lived credentials" property. Redpanda's ADP 2025-10-28 announcement names short-lived credentials as the first AAC primitive; mechanism not disclosed (no IdP / token- exchange walked), but the property claim binds the Fly.io STS+OIDC mechanism shape to the agent audience.
  • sources/2026-04-14-redpanda-openclaw-is-not-for-enterprise-scale — Sharpest canonical statement of the per-operation short-lived credential flow in the agent audience. Redpanda 2026-04-14 Openclaw is not for enterprise scale post canonicalises the flow verbatim: "When it needs to take an action, the gateway requests a short-lived, scoped token from the vault for exactly that operation." Introduces the concepts/token-vault as the credential- minting substrate distinct from the gateway, and positions per-operation minting (not per-session minting) as the correct altitude for agent tool calls — binding short-lived credential auth to the four- component agent production stack's component #3. Mechanism (protocol, token format, vault implementation) still not disclosed; the property + architectural role is canonicalised.
Last updated · 542 distilled / 1,571 read