JWT cty Header
The cty (content type) header parameter indicates the media type of the secured content inside a JWS or JWE. Nested JWTs often set cty to JWT so verifiers know the payload is itself a JWT that must be processed further after the outer layer verifies. For ordinary access tokens with JSON claims, cty is frequently omitted. When present, cty helps libraries decide how to parse the payload after signature verification or decryption succeeds. Like other header fields, cty is only trustworthy after cryptographic verification completes successfully. Incorrect assumptions about cty can cause applications to skip nested verification steps or mis-parse binary payloads in distributed authentication systems that process layered tokens.
Why It Matters
Nested JWT patterns appear in some federation and encryption designs. If your stack uses nesting, failing to honor cty can leave an inner token unchecked and still trusted by downstream code. If you do not use nesting, omit cty to avoid confusion for operators and libraries. Security reviews should confirm that any cty-driven branching still verifies every layer and never trusts unverified headers for access control decisions across microservices and edge gateways.
Related Terms
Related Comparisons
Related Tools
Related Articles
Frequently Asked Questions
Do I need cty for normal access tokens?
Usually no. Omit cty for ordinary JSON claim sets. Add cty only when nesting JWTs or when a profile requires an application-specific media type after successful signature verification.
Is cty protected by the signature?
In JWS, cty in the protected header is covered by the signature. Always verify first; never let unverified cty drive parsing, decryption, or authorization side effects.
What happens if cty is wrong?
Parsers may treat the payload incorrectly or skip nested verification. Fix the issuer configuration; never disable outer or inner signature checks to work around nested token mistakes.