Allow as little as your infrastructure needs. RFC 7519 permits "some small leeway, usually no more than a few minutes" when checking exp and nbf. Many teams start at 30 to 60 seconds, which is a practical choice and not a spec number, then fix their clocks rather than widen the window.
What the time claims mean
A JWT carries up to three time claims. RFC 7519 defines them:
| Claim | Meaning | Validator rule |
|---|---|---|
| exp | Expiration time | The current time must be before it |
| nbf | Not before | The current time must be on or after it |
| iat | Issued at | Tells you the age of the token, no fixed rule |
For exp, the RFC says the JWT must not be accepted on or after that time. For nbf, it must not be accepted before it. For both, implementers may provide small leeway, usually no more than a few minutes, to account for clock skew.
Why skew happens
The issuer and the verifier run on different machines. If their clocks disagree by a few seconds, a freshly issued token can look "not yet valid" to one service, or a still valid token can look expired to another. Container hosts, laptops and long running VMs that lost time sync are common causes.
A practical way to choose
- Measure first. Check how far apart your issuer and services drift. If you run time sync, the answer is usually under a second.
- Pick a small leeway above that, such as 30 to 60 seconds. This is a common starting point, not something the standard mandates.
- Apply the same value in every service, through a shared library setting, so behaviour is predictable.
- Do not stretch leeway to hide a broken clock. Alert on hosts without time sync instead.
- Keep access token lifetimes short. A long leeway on a short lived token is a large share of its life.
Why a big leeway is a risk
Leeway extends the time a stolen token works. If your access tokens last five minutes and you allow five minutes of leeway, an expired token stays usable for double its intended life. For high value actions, you can also check iat and require recent authentication for sensitive operations.
What leeway does not fix
Leeway deals with clock disagreement. It does not replace the other checks: signature, algorithm, issuer, and audience. A token that is within time bounds but meant for a different API should still be rejected.
Test it
Write three tests: a token that expired 5 seconds ago (should pass with leeway), one that expired well beyond your leeway (must fail), and one with an nbf in the future beyond leeway (must fail).
Try it yourself
Click through it at your own pace, or open it full screen. Find the JWT library in the inventory and note its version, since default leeway settings differ between libraries.
Quick check
Should leeway apply to both exp and nbf?
RFC 7519 mentions small leeway for both claims. Most libraries expose a single setting that covers both.
Is a negative iat check useful?
Rejecting tokens issued far in the future can catch odd clocks or forged tokens. It is a local policy choice, not a rule from the RFC.
Safeguard's SBOM and dependency scanning shows which JWT libraries and versions you ship, so you can check their defaults and advisories. A free scan is available.
Sources
Last reviewed: 19 October 2026.
