2026-09-04 · 6 min read · Rahul Chitturi
- jwt
- json
- security
A JWT header or payload is a JSON object, and duplicate member names are ambiguous across parsers. One library may keep the first value, another the last, and a security filter may inspect a different value from the authorization layer.
A token containing two aud, exp, role, or alg-like members should not be normalized into an apparently valid token. Ambiguity at a signed security boundary must fail closed.
Inspect structure without granting trust
Use only synthetic or redacted fixtures to compare the raw decoded JSON text with the object returned by each production component. Ordinary object display can hide duplicates because they have already been collapsed.
- Reject duplicate member names before claim interpretation
- Apply the same strict JSON policy to protected headers and payloads
- Allowlist algorithms from server configuration
- Verify the signature before trusting any claim value
Keep one validation boundary
Avoid decoding in a gateway, reserializing the claims, and asking another service to authorize from the rewritten object. Each transformation can erase evidence or change number and string handling.
Use a maintained JWT implementation with a documented duplicate-name policy, then validate issuer, audience, time, token type, and application claims in one coherent profile.
A Flashman workflow
Use the JWT tool to inspect harmless compact fixtures, Base64 to view exact encoded segments, JSON formatter only after checking raw member names, and diff to compare parser outputs.
Test duplicate registered and private claims, escaped-equivalent names, nested objects, large numbers, invalid signatures, unsupported algorithms, and every gateway and language runtime on the request path.