How to Find JWT Authentication Flaws in APIs

How to Find JWT Authentication Flaws in APIs

JWTs (JSON Web Tokens) are everywhere in modern APIs. They are convenient. They are also easy to get subtly wrong.

This guide focuses on flaws hunters actually report — written so you can skim, then deep-dive.

Quick takeaway: Decode the token → check algorithm and signature handling → tamper claims carefully → prove unauthorized access with before/after requests.

JWT in 30 seconds

A JWT usually has three parts:

1. Header (algorithm, type)
2. Payload (claims like sub, role, exp)
3. Signature

Anyone can read the payload. Trust comes from verifying the signature with the right key and algorithm.

High-value checks

1) Algorithm confusion / none

Older or custom verifiers sometimes accept:

• alg: none
• Switching RS256 → HS256 with the public key used as an HMAC secret

If signature checks are weak, you may forge a valid-looking token.

2) Weak HMAC secrets

If the app uses HS256 with a guessable secret, offline cracking may be possible. Only attempt this when rules allow and rate limits / ethics are respected.

3) Claim tampering after verified signature mistakes

If the API verifies signature incorrectly, try changing:

• sub / user id
• role / admin
• exp (expiry)

4) Acceptance of tokens after logout / rotation gaps

Not every issue is crypto. Sometimes refresh flows or revocation are missing.

Comfortable testing workflow

1. Capture a valid JWT from login
2. Decode it (jwt.io-style tools or Burp extensions)
3. Note alg, claims, and kid
4. Create a modified token in a controlled way
5. Replay an authenticated API call
6. Compare authorized vs unauthorized responses

Report tips

Show:

• Original token claims (redact secrets)
• Exact modification
• Endpoint that accepted it
• Impact (access another user, elevate role, skip expiry)

Fixes worth listing

• Explicit allowlist of algorithms
• Strong key management
• Verify signature on every trust decision
• Short expiries + refresh rotation
• Authorize on the server with real permissions, not only a role string in a token

---

Original Bugflare article. Learning direction aligned with PortSwigger JWT academy topics. Stay within program rules for offline cracking and token reuse.