Ephemeral Credentials

A credential whose lifetime is short enough — typically a day or less, often minutes — that it expires before it can spread. The point isn't just "shorter rotation cycle"; it's that there is nothing to rotate. The credential is minted per session, used, and discarded.

Why this matters

Long-lived credentials accumulate problems linearly in time: people who have seen them, places they've been copied, attempts to guess them, usage against cryptographic limits. Ephemeral credentials reset the clock continuously. A leaked one-hour token is mostly a non-event by the time anyone notices. (See long-lived-keys for the full failure-mode catalog.)

The other reason: rotation is a process, and processes that aren't exercised rot. Quarterly rotation runbooks tend to be wrong by the time you need them in an emergency. A system that rotates every minute by construction can't have stale rotation tooling.

How it works

Ephemeral credentials need a long-lived trust anchor that mints them. The substitution isn't "no long-lived keys anywhere" — it's "fewer long-lived keys, concentrated in infrastructure that exists to manage them":

• OIDC federation. A workload presents a signed identity assertion (from GitHub Actions, AWS IAM, an IdP) to a resource server, which mints a short-lived access token in exchange. The trust anchor is the OIDC issuer's signing key, which is one well-managed long-lived key per issuer instead of one per user/workload.
• Just-in-time provisioning. A bastion or control plane checks whether the requester is currently allowed in (via SSO, MFA, ticketed access) and mints a per-session credential. AWS EC2 Instance Connect and SSH certificate authorities work this way.
• Signed assertions. SSO replaces per-app passwords with per-login signed assertions from the IdP. The user never has a long-lived secret at the app; the app trusts the IdP signature.

Examples in practice

• EC2 Instance Connect — replaces persistent SSH keys with per-session credentials minted after a fresh authorization check.
• PyPI / crates.io / NPM Trusted Publishers — a specific GitHub Actions workflow exchanges its OIDC token for a short-lived publish credential. No stored registry token. Astral's release pipeline is built around this; see open-source-security-astral.
• SSO assertions (SAML, OIDC) — per-login signed assertions instead of long-lived per-app passwords.
• AWS STS / GCP service-account impersonation — workloads assume a role for a session-bounded credential rather than holding a static key.
• SSH certificate authorities — short-validity SSH certs minted by a CA after authentication, instead of long-lived authorized_keys entries.

Limits

The trust anchor remains long-lived. An IdP signing key, an SSH CA key, an OIDC issuer key — these are all credentials whose compromise would be catastrophic. The win is concentration: one or a handful of carefully-managed keys instead of N long-lived keys spread across teams. See long-lived-keys for the residual-management practices (scope tightly, mathematical lifetime bounds, quarterly rotation, dedicated owners).

See also

• long-lived-keys — the case for making this substitution
• supply-chain-security — the most common context where stored registry tokens are the wrong answer
• jwt-for-sessions / paseto — short-lived bearer tokens, related but not the same use case