Why do short-lived OIDC tokens still create risk in compromised workflows?

Why short-lived OIDC tokens still matter after issuance

Short expiry reduces the window for replay, but it does not neutralise abuse that happens while the workflow is live. In a compromised runner, the attacker can use the same legitimate path the job uses to obtain or present a token, so the issue is less about token age and more about who controls execution at the moment the token is minted or consumed.

That is why OIDC risk is often concentrated around the workflow boundary rather than the token itself. If the build, deploy, or publish step is already trusted to request access, a hostile step can act quickly enough to do damage before expiry becomes a meaningful defence.

When you evaluate this pattern, treat token lifespan as only one control variable. Audience restriction, claim validation, issuer trust, and the ability to constrain where the token can be replayed all shape whether a short-lived token is merely inconvenient to steal or actually difficult to abuse. The same trust boundary is documented in OpenID Connect Core 1.0 and the OAuth flow that underpins it.

How a compromised workflow turns a valid token into an attack path

A short-lived OIDC token is still useful to an attacker if the compromise happens before, during, or immediately after issuance. In CI/CD and release automation, the runner itself may be the trusted subject that mints the token, exchanges it, or passes it to a cloud or package service. If malicious code executes inside that runner, it can simply ask for the same access the legitimate job would have received.

The practical risk is therefore delegated authority with a narrow time box. The token may expire quickly, but the attacker does not need persistence if the workflow can publish artifacts, read secrets, call an API, or modify infrastructure in a few seconds. In that sense, the token is a momentary instrument of the compromise, not a meaningful barrier to it.

This is why controls around workflow identity and token audience matter as much as expiry. NHI Authentication Guide covers the credential paths commonly used in machine and workload authentication, and the distinction between legitimate issuance and unsafe reuse is central to understanding the boundary.

For the underlying authorization model, RFC 6749: The OAuth 2.0 Authorization Framework and RFC 8707: Resource Indicators for OAuth 2.0 are useful references because they explain how tokens should be scoped to the intended resource instead of being broadly reusable.

What practitioners should verify before trusting short-lived tokens

Short-lived OIDC tokens are strongest when they are paired with proof that the workflow is still trustworthy at the moment of use. If the runner can be modified, injected into, or coerced into minting a token for the wrong audience, then the expiry window does little to reduce impact. The key question is not only “how long does the token live?” but “what can the issuing workload do while it is alive?”

Practitioners should verify that the token cannot be replayed outside the intended service boundary, that workflow permissions are minimal, and that the issuance path is not reusable across unrelated environments. Identity Provider and SSO Security Guide is relevant here because the same trust chain, federation trust, and token-handling failures appear when token issuance is not tightly constrained.

A useful operational habit is to treat any workflow that can mint a production-facing token as a privileged control point. If that job also runs untrusted code, third-party actions, or mutable build steps, the issuance path should be assumed exposed until proven otherwise.

Risk and Threat Considerations

Short-lived OIDC tokens reduce standing exposure, but they do not stop an attacker who has already gained execution inside the workflow. The practical threat is credential use through legitimate issuance, which can let an adversary publish packages, call APIs, or access services before the session expires.

Failure mechanism: Malicious code inside the trusted runner mints or captures a token, then uses it immediately against the intended audience before expiry, often without needing to persist the token at all.

Impact: The attacker can perform real actions under the workflow’s identity, which can mean supply-chain compromise, cloud access, or unauthorized service changes even when the token lifetime is brief.

Practitioner Guidance

What to prioritise: Focus first on the trust boundary around token issuance, not on shortening expiry further. If the runner can execute untrusted code, isolate or harden that step before assuming token lifetime will protect you.

What to verify: Confirm the token audience is tightly restricted, the job has no unnecessary publish or deploy rights, and the workflow cannot mint broadly usable credentials for other services. If those conditions are not true, expiry alone is not a meaningful control.

Common mistake: Treating short-lived tokens as a substitute for workflow integrity. A compromised job that can request legitimate access is already inside the control boundary, so the real question is blast radius, not just token age.

Practitioner takeaway: Short-lived OIDC tokens are a reduction in exposure, not a guarantee of safety; once code execution is compromised, the decisive control is whether the workflow can still obtain or use authority in a narrowly bounded, observable way.

Related resources from NHI Mgmt Group

• Why do short-lived OIDC tokens still create meaningful supply chain risk?
• Why do short-lived tokens still create security risk?
• Why do short-lived tokens still create major risk in CI/CD environments
• Why do short-lived per-tool tokens reduce risk but still fail to stop a compromised AI agent from doing the wrong thing?