Token Expiration
Token expiration is the policy and mechanism that limits how long a credential remains valid. For JWTs, expiration is enforced primarily via the exp claim, sometimes combined with nbf (not before). Short expiration shrinks the attack window if a token leaks. Longer expiration improves UX but increases risk. Refresh tokens extend sessions while keeping access tokens short-lived. 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. Document expected behavior for client teams so tokens are issued, stored, and validated consistently across services.
Why It Matters
Expiration is your primary compensating control when tokens cannot be instantly revoked at scale. Define lifetimes per token type: minutes for access, days for refresh, seconds for one-time flows. Monitor clock skew and document renewal behavior for client teams. 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.
Related Terms
Related Tools
Related Articles
Frequently Asked Questions
What happens if I omit expiration?
Tokens may remain valid indefinitely unless you implement external revocation. Always set exp for production tokens. 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.
How do clients handle expiration?
Detect 401 responses or decode exp client-side, then refresh or redirect to login before retrying requests. 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.
Should refresh tokens expire?
Yes. Use absolute and inactivity timeouts, plus rotation, to bound long-lived session risk. 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. Test edge cases with expired, malformed, and wrong-algorithm tokens in CI before shipping auth changes.