JWT expiry

What it means

JWT expiry is set by the exp claim, a time given in seconds since 1 January 1970. RFC 7519 says a token must not be accepted on or after that moment. It is part of the signed content, so nobody can extend it without breaking the signature.

Two related claims help. iat records when the token was issued, and nbf sets when it first becomes valid. Together they define a window in which the token is acceptable.

Why it matters

A JWT is checked by signature alone, so it keeps working until it expires. If the expiry is missing, set years ahead or never checked, a token stolen once works indefinitely. The signature will still be perfectly valid.

Expiry is also the main way you cancel a stateless token, since the server keeps no record. A short life limits the harm of any leak. A long one turns every leak into a long-running problem, and revocation becomes the only brake.

How it shows up

You meet it in the payload of every access token and ID token. Libraries check it for you by default, but not always, and not for hand-written decoding. Some also allow a few seconds of clock skew, which is fine, while minutes of leeway is not.

The mistakes repeat. A token with no exp that the server happily accepts. Decoding without verifying. Expiry set to a year "for convenience". Refresh tokens that never expire. Servers whose clocks drift. Check that a token one second past expiry is refused.