Cybersecurity glossary
What is the Expiration Claim (exp)?
Learn what the JWT expiration claim (exp) is, how exp bounds token lifetime, why clock skew matters, and how short-lived tokens reduce replay and theft impact.
Definition
The expiration claim (exp) is a registered JWT claim containing a NumericDate after which the token must not be accepted for processing, providing a mandatory lifetime bound that limits the usefulness of stolen or leaked credentials.
Why expiration matters
Bearer tokens remain powerful until something stops them. The expiration claim (exp) is the simplest stop condition: after a timestamp, verifiers must refuse the token.
Short, enforced expiry is one of the highest-leverage JWT controls. It will not prevent theft, but it shrinks the blast radius from days to minutes.
What exp controls
Hard validity deadline
Defines the last moment a token may be accepted for processing.
Replay window size
Bounds how long stolen tokens remain useful to attackers.
Operational certainty
Gives incident responders a maximum residual risk after leak discovery.
Lifecycle pairing
Works with refresh flows so sessions continue without immortal access JWTs.
Enforcing expiration correctly
Issuer sets exp at mint time
Authorization servers compute expiry from policy (for example, now + 5 minutes).
Token is distributed to the client
Clients store and present the token only within its lifetime.
Verifier checks signature first
Cryptographic validation establishes a trusted claim set.
Compare exp to current time
Reject when now is on or after exp, applying only minimal skew leeway.
Client refreshes if needed
Refresh token flows obtain a new access token before expiry impacts UX.
Monitor expiry-related failures
Spikes may indicate clock issues, client bugs, or token scraping retries.
Lifetime design trade-offs
| Access token lifetime | UX impact | Security impact |
|---|---|---|
| 1–5 minutes | Needs solid refresh handling | Very small replay window |
| 15–60 minutes | Common API default | Moderate residual risk after theft |
| Many hours/days | Fewer refreshes | High replay and revocation pain |
| No exp | Appears convenient | Unacceptable for auth tokens |
Expiration hardening checklist
- Require exp on all authentication and access JWTs.
- Keep access-token lifetimes short; push longevity into refresh rotation.
- Use minimal clock skew leeway and keep NTP healthy on verifiers.
- Reject expired tokens even if other claims look perfect.
- Align JWKS key retirement windows with maximum token lifetime.
- Avoid sliding expiry by rewriting exp client-side—only issuers mint tokens.
- Alert on tokens presented far beyond exp as probing signals.
- Document lifetime SLOs per token type (access, ID, service account).
The practical takeaway
The expiration claim (exp) is the JWT’s mandatory shelf life. Enforce it strictly and keep it short for access tokens.
Combine with nbf/iat validation, refresh rotation, and secure storage so expiry is a control—not a false sense of safety.
Related security terms
Not Before Claim (nbf)
Companion time claim that controls when a token becomes valid.
Issued At Claim (iat)
Records when the token was minted for age and freshness checks.
JWT Token Replay
Abuse of still-valid tokens that short expiry helps limit.
Access Token
API credential whose lifetime is usually set via exp.
JWT Claim
Overview of JWT payload assertions including time claims.
Frequently asked questions
What is the exp claim in simple terms?
exp is the “use by” date of a JWT. After that Unix timestamp, APIs should reject the token even if the signature is still valid.
What format does exp use?
A NumericDate: seconds since the Unix epoch (1970-01-01T00:00:00Z UTC), not milliseconds.
Is exp required?
RFC 7519 marks it optional in the abstract, but JWT best practices and virtually all auth deployments treat exp as mandatory for access tokens.
What is clock skew?
Small time differences between issuer and verifier clocks. Libraries often allow a limited leeway, but large skew windows weaken expiry.
How short should access token exp be?
As short as UX and architecture allow—often minutes. Use refresh tokens for longer sessions instead of multi-day access JWTs.
Does exp replace revocation?
No. exp bounds damage but cannot instantly invalidate a token after compromise unless TTL is already tiny or a denylist exists.
What if exp is missing?
Secure APIs should reject authentication tokens without exp rather than treating them as immortal.
References
Explore authoritative guidance and frameworks related to expiration claim (exp).
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.