Recognize the three JWT segments
A common signed JWT has a Base64url-encoded header, a Base64url-encoded payload, and a signature separated by periods. The header identifies details such as the algorithm; the payload contains claims. Encoding makes these values portable, not secret.
Treat decoded claims as untrusted
Anyone who can create text can assemble a plausible header and payload. Decoding proves only that the segments can be read. Signature verification must use an allowed algorithm and the correct trusted key before an application relies on any claim.
- Never accept an unexpected algorithm from the token without policy checks.
- Do not use a decoded role or user ID as authorization.
- Avoid pasting active bearer tokens into third-party services.
Check registered claims in context
The exp and nbf claims are NumericDate values expressed as seconds since the Unix epoch. The issuer and audience must match values expected by the receiving application. Clock tolerance should be small, deliberate, and enforced by the verifier.
Verify at the system boundary
Verification belongs where the token grants access, normally in the API or backend receiving it. Validate the signature, algorithm, key selection, issuer, audience, expiration, not-before time, and application-specific claims as one policy.
Decoded is not verified
| Action | What it proves | What it does not prove |
|---|---|---|
| Decode header and payload | The segments contain readable data | That the data came from a trusted issuer |
| Inspect exp and nbf | The token states time limits | That those values are authentic |
| Verify the signature | The signed bytes match a trusted key | That issuer, audience, and authorization are correct |