2026-08-30 · 6 min read · Rahul Chitturi
- jwt
- security
- debugging
A JWT header may identify the outer object with typ and describe nested content with cty. Gateways and libraries disagree on how strictly they require these hints, so a validly signed token can still fail before claim validation.
The common symptom is an unsupported token type, malformed payload, or signature error caused by sending an encrypted or nested token to a component that expects plain claims.
Separate metadata from trust
Decode each compact layer only to understand its structure. Header values are attacker-controlled until the relevant signature or authenticated encryption check succeeds.
- Use typ to identify the outer application token profile when required
- Use cty to describe a nested JWT payload
- Allowlist expected algorithms for every layer
- Reject extra nesting and unsupported serialization forms
Validate the right claims at each layer
Document which component decrypts, which verifies, and which authorizes. A nested access token may require decryption at the gateway and signature verification by the resource server before issuer, audience, expiry, and scope checks.
Do not fix interoperability by skipping type or algorithm checks. Compare the failing token with a synthetic known-good token from the same issuer profile.
A Flashman workflow
Use the JWT tool to inspect safe test headers and claims, Base64 for individual encoded fixtures, JSON formatter for metadata, and diff for profile comparisons. Never paste live bearer tokens into shared tickets.
Add tests for plain, signed-and-encrypted, wrong content type, unexpected algorithm, excessive nesting, and invalid inner claims.