ReferenceIntermediate4-6 min reference
JWT Claims & Safe QA Checks
A JWT (JSON Web Token) is three base64url parts — header.payload.signature — joined by dots. The payload is encoded, not encrypted: anyone can read it, so it must never contain secrets. This sheet covers the standard claims and the checks QA can run safely. Token forgery and signature attacks belong in authorized security testing (linked below).
Anatomy
| Part | Contains |
|---|---|
| Header | alg (signing algorithm, e.g. RS256), typ: JWT |
| Payload | The claims (see below) |
| Signature | Verifies the token wasn't tampered with — checked by the server, not the client |
Standard (registered) claims
| Claim | Meaning | QA check |
|---|---|---|
iss | Issuer | Matches your auth server |
sub | Subject (user/entity id) | Identifies the right user |
aud | Audience | Matches your API |
exp | Expiry (epoch seconds) | In the future; expired ⇒ 401 |
nbf | Not before | Token isn't accepted early |
iat | Issued at | Sane timestamp |
jti | Token id | Unique; supports revocation |
What QA can safely verify
- Decode the payload (e.g. with the JWT decoder utility) and assert
sub,aud,iss, and scopes/roles are correct. - An expired token (
expin the past) is rejected with401. - A token for one user cannot access another user's data.
- The token is sent as
Authorization: Bearer …over HTTPS and never appears in logs or URLs. algis an expected algorithm — flagalg: noneto the security team (don't exploit it yourself).
When to use
Asserting identity/role claims in API tests, or reviewing an auth flow. For signature, alg:none, and tampering tests, use authorized security testing — see the link below.
Common mistakes
- Treating the payload as secret — it's readable by anyone holding the token.
- Validating only that a token exists, not that its claims are correct.
- Ignoring
exp/nbf, so expiry and clock-skew bugs slip through. - Logging full tokens in test output or CI artifacts.
// Related resources