Three separate questions
When inspecting a JWT, ask whether it is structurally decodable, whether its signature is valid, and whether its claims are acceptable for the current application. These are separate checks. A neatly decoded payload can still be forged, expired or intended for another service.
Server-side verification should restrict expected algorithms and keys. It should not simply accept the algorithm declared by untrusted token input.
Claims that commonly cause rejection
The exp claim limits the time after which a token is unacceptable; nbf can delay when it becomes valid. iss identifies the issuer and aud describes the intended audience. Small clock differences can matter near time boundaries, but large tolerance windows weaken the check.
- Compare timestamps as UTC Unix time
- Confirm issuer exactly
- Check that the current service is an allowed audience
- Account for deliberate, limited clock skew
Handle tokens as credentials
JWT payloads are readable and should contain only necessary claims. Production tokens can grant access even if the payload itself looks harmless. Avoid placing them in screenshots, support tickets, analytics events or client logs. Use short-lived access tokens and a deliberate revocation or rotation strategy where the risk requires it.
References and further reading
These primary or authoritative references support standards-dependent details. LipiCode’s explanations and examples are independently written for this workflow.