JWT Expiration Claim

The JWT expiration claim defines the point after which a token must no longer be accepted. It limits how long a token can be replayed if stolen or leaked. Enforcing expiration reduces the window of abuse and helps prevent old credentials from remaining usable indefinitely.

Expanded Definition

The JWT expiration claim, commonly represented as RFC 7519 exp, is a time-bound validity marker that tells a verifier when a token must be rejected, even if its signature is otherwise valid. In NHI environments, that matters because service-to-service trust often depends on short-lived tokens rather than interactive user sessions.

Definitions vary across vendors on how strictly expiration is enforced relative to clock skew, cached authorisation, and downstream session handling. The control objective is simple: a token should stop being usable at or before its expiry, and no surrounding system should silently extend that trust window. This is especially important when JWTs are used by agents, workloads, or automation that can retry requests at machine speed.

The concept is often confused with revocation, but expiration is not a replacement for active invalidation. Expiration limits how long a stolen token remains useful; it does not by itself detect compromise. The most common misapplication is treating exp as a complete security control, which occurs when teams issue long-lived JWTs and assume signature verification alone prevents replay.

Examples and Use Cases

Implementing JWT expiration rigorously often introduces operational friction, requiring organisations to weigh tighter replay protection against more frequent token renewal and potential service instability.

• A workload token issued for one API call expires in minutes, reducing replay risk if intercepted during transit.
• An AI agent receives scoped access to a toolchain, and its JWT is set to expire quickly so the agent must re-authenticate before longer workflows continue.
• A CI/CD job exchanges a short-lived token for deployment access, aligning with NHI lifecycle controls described in the NHI Lifecycle Management Guide.
• A platform team reviews token TTLs alongside guidance in the Top 10 NHI Issues to identify overextended machine credentials.
• An identity gateway validates exp against the issuer’s clock policy and the implementation guidance in OWASP Non-Human Identity Top 10.

In practice, teams also pair expiration with rotation and scoped audience claims, because a short-lived token only helps if the surrounding issuance model does not immediately replace it with an equally risky long-lived credential.

Why It Matters in NHI Security

JWT expiration is a core boundary for controlling replay, lateral movement, and the lifetime of compromised automation credentials. When exp is missing, too permissive, or ignored by an intermediary service, stolen tokens can remain effective far longer than intended, particularly in distributed systems where multiple services independently validate identity.

This issue is tightly connected to secret exposure and machine identity sprawl. NHIMG research on The State of Secrets in AppSec found that the average estimated time to remediate a leaked secret is 27 days, which means short token lifetimes are often the only practical limit on abuse during the exposure window. The same problem pattern appears in the LLMjacking: How Attackers Hijack AI Using Compromised NHIs research, where stolen credentials are abused at machine speed.

For practitioners, expiration must be understood as one layer in a larger NHI defense model that also includes rotation, audience restriction, and robust validation at every trust boundary. Organisations typically encounter the impact only after a token is replayed from an unexpected source, at which point expiration policy becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• What do security teams get wrong about token expiration in JWT authentication?
• How should security teams use the JWT aud claim in production applications?
• What breaks when JWT claim semantics are not standardised?
• JWT Claim Trust Boundary