JWT Claims, Expiration, and Safe Token Inspection
A JSON Web Token can be decoded locally to help diagnose an authentication flow, but decoded claims are not proof that the token is valid. Treat a token as sensitive and separate inspection from verification.
Read the three parts correctly
A JWT normally has a header, payload, and signature separated by periods. The first two parts are Base64URL-encoded JSON, so they can be read without a signing key. The signature is what binds the claims to a trusted issuer.
If a token is malformed, start by checking the number of segments and whether each encoded JSON section can be decoded. Do not paste a live customer token into a third-party service.
Check time claims with the correct clock
The exp claim usually represents a Unix timestamp. Compare it with the environment time, not just your laptop clock. Also inspect iat and nbf when tokens appear to expire immediately or are rejected during a deployment.
- Decode the token locally.
- Convert exp, iat, and nbf to readable dates.
- Compare issuer, audience, and scopes with the configuration expected by the receiving service.
Decoding is not verification
Never authorize a request based solely on a decoded payload. Verification must check the signature, expected signing algorithm, issuer, audience, and relevant time claims using trusted key material. Avoid accepting an algorithm merely because the token header declares it.