Validate a JWT Token — Quickstart
Decoding a JWT is not authentication. This quickstart shows how to verify signatures, pin algorithms, check exp/iss/aud claims, and debug failures with the JWT Validator so your API never trusts a forged, expired, or algorithm-confused token in real production systems.
Last updated August 26, 2026
Steps
- 1
Remember that jwt.decode() only reads claims — jwt.verify() (or equivalent) checks the cryptographic signature.
- 2
Always pass an explicit algorithms allowlist (for example ['HS256'] or ['RS256']) to prevent algorithm-confusion attacks.
- 3
Validate exp on every access token; set iss and aud for production multi-service APIs.
- 4
Use the JWT Validator during development to reproduce failing tokens with your secret or public key.
- 5
Ship auth middleware that returns 401 for missing, expired, or invalid tokens before any business logic runs.
Frequently Asked Questions
Why does my token fail verification?
Common causes: wrong secret or public key, expired exp, whitespace in env-stored secrets, algorithm mismatch, or a tampered payload. Reproduce with the JWT Validator first.
Should I verify on every request?
Yes. Every protected endpoint must verify the token before trusting any claim. Caching decoded claims without re-verify is a common vulnerability.
Is decode enough for logging?
Decode-only is fine for non-sensitive debugging logs. It is never enough to authorize a request or trust roles inside the payload.
What if alg is none?
Reject it. Libraries that omit an algorithms allowlist have historically accepted alg:none. Always pin allowed algorithms on verify.
Continue
Related tools and reading on JWTSecrets.