2026-09-04 · 8 min read
- jwt
- json
- security
JWT protected headers and claim sets are encoded as JSON objects. If a token contains duplicate member names, different parsers may keep the first value, keep the last, or reject the object. A gateway and an application can therefore reach different conclusions from the same signed bytes.
Security decisions require one unambiguous representation. Reject malformed or ambiguous JSON before using headers to select verification behavior or claims to authorize a request.
Parse without erasing evidence
Duplicate names are easiest to detect while parsing the original decoded bytes. Converting immediately into a map can discard earlier occurrences, while reserializing produces a different JSON text that no longer shows what was signed.
- Apply strict duplicate-name checks to every JWT JSON object.
- Reject invalid UTF-8 and malformed JSON rather than repairing it.
- Bound encoded segment, decoded byte, depth, and member counts.
- Keep original compact segments through signature verification.
Separate header input from verification policy
The alg, kid, typ, and key-related headers are attacker-controlled until verification succeeds. Use endpoint configuration to allowlist algorithms and trusted key sources, then treat the header only as constrained key-selection input.
Do not let a token switch between symmetric and asymmetric verification, fetch arbitrary key URLs, or fall back to an unrelated key after one strategy fails. Validate unsupported critical parameters before accepting the token.
Validate claim names and types
After cryptographic verification, enforce the token profile's expected issuer, audience, time, subject, nonce, and authorization claim types. A string where an array is expected, a floating-point time, or a nested role object should not be coerced silently.
- Use exact registered claim semantics.
- Constrain clock skew and token lifetime.
- Keep authentication identity separate from permissions.
- Reject unknown critical application claims when the profile requires it.
Build cross-component fixtures
Use Flashman's JWT tool to inspect synthetic tokens, Base64 tool for exact segments, JSON formatter for valid unambiguous objects, diff for parser outputs, and timestamp converter for public time fixtures. Final verification belongs in the trusted server library.
Test duplicate headers and claims, escaped-equivalent names, claim type changes, invalid Unicode, large numbers, algorithm mismatches, unknown keys, invalid signatures, and every proxy, gateway, runtime, and JWT library in the production path.