exp (Expiration) Claim
The exp (expiration) claim is a registered JWT claim containing a Unix timestamp (seconds since epoch) after which the token must be rejected. Verifiers should always check exp — tokens without expiration remain valid indefinitely, which is a critical security flaw. Most JWT libraries validate exp automatically during verify(). exp is a NumericDate per RFC 7519 and must be compared against the verifier's trusted clock. Implementations across Node.js, Python, Go, Ruby, and Java follow the same RFC standards, so concepts transfer directly between stacks. Security reviews should treat this as part of your full authentication threat model, not an isolated configuration detail.
Why It Matters
Short exp times limit damage if a token is stolen. Access tokens should expire in 15–60 minutes; use refresh tokens for longer sessions. Never issue production tokens without exp. Clock skew between issuer and verifier should be handled with a small leeway window, typically 30–60 seconds. Getting this wrong often surfaces only after an incident, when forged or replayed tokens expose gaps in validation or secret handling. Platform teams should encode these rules in libraries, linting, and deployment checklists so individual services cannot drift silently. Pair technical controls with monitoring: log verification failures, track unusual token lifetimes, and alert on spikes in 401 responses.
Code Example
{
"sub": "user_42",
"exp": 1720454400,
"iat": 1720450800
}Related Terms
Related Tools
Related Articles
Frequently Asked Questions
What is a good access token lifetime?
15–60 minutes for APIs. Shorter for high-security environments. Pair with refresh tokens for longer user sessions. Consult your JWT library documentation for exact option names, defaults, and error types. When in doubt, prefer stricter validation and shorter token lifetimes over permissive shortcuts.
What happens when exp passes?
The token must be rejected. Clients should use a refresh token flow to obtain a new access token without re-authentication. Consult your JWT library documentation for exact option names, defaults, and error types. When in doubt, prefer stricter validation and shorter token lifetimes over permissive shortcuts.
Can exp be a string?
No. exp must be a NumericDate (Unix timestamp in seconds). String values should be rejected during validation. Consult your JWT library documentation for exact option names, defaults, and error types. When in doubt, prefer stricter validation and shorter token lifetimes over permissive shortcuts.