JWT Claims Checklist (iss, aud, exp, nbf)
Signed JWTs still need claim hygiene. Use this checklist to set and verify exp, nbf, iss, aud, and sub so tokens cannot be replayed across environments or used after they should die — then debug failing claims with the JWT Validator.
Last updated August 26, 2026
Steps
- 1
Require exp on every access token and keep lifetimes short (minutes to an hour for APIs).
- 2
Set iss to your auth service identity and reject tokens with unexpected issuers.
- 3
Set aud to the intended API or client ID and reject tokens meant for another audience.
- 4
Use nbf when you need not-before windows; account for modest clock skew on verifiers.
- 5
Put stable subject identifiers in sub — avoid putting secrets or PII in custom claims.
- 6
Paste a sample token into the JWT Validator to confirm claim failures match your middleware rules.
Related Articles
Frequently Asked Questions
Is exp enough by itself?
exp is mandatory for access tokens, but iss and aud prevent cross-service reuse. Use all three for production multi-service APIs.
How much clock skew should I allow?
A small skew (often 30–60 seconds) absorbs NTP drift between servers. Large skews weaken expiry guarantees and should be avoided.
Should refresh tokens use the same claims?
Yes for iss/aud/sub discipline, but lifetimes and storage differ — refresh tokens are longer-lived and need stricter storage and rotation.
What if verification fails only on aud?
Your token was likely minted for another API. Fix the issuer configuration or reject the token — do not disable aud checks just to make it pass.