What is a nested JWT, and why is the payload signed before it is encrypted?
answer
- Two containers, two different properties
- Encryption alone does not prove authorship
- Which layer is visible to a relaying party
- cty tells the recipient what it decrypted
- RFC 7519 states the ordering preference
basics
~20 sA nested JWT is a JWT whose payload is itself a JWT — in practice a JWS wrapped inside a JWE, flagged by cty set to JWT on the outer header. Signing first binds the signature to the real claims and keeps origin proof from being stripped or replaced.
solid answer
~50 sA nested JWT is defined in RFC 7519: the payload of the outer token is another JWT, and the outer header sets `"cty": "JWT"` so the recipient knows the decrypted bytes are a token rather than arbitrary content. The normal construction is **sign then encrypt** — produce a JWS over the claims, then use that compact JWS string as the plaintext of a JWE. You need both because the two containers give different properties: a JWE hides the claims but, when the content key is wrapped under the recipient's public key, proves nothing about who created it, since anyone with that public key could have. Signing first means the signature covers the actual claims, so verifying it tells you who asserted them. Encrypting first and signing the ciphertext would only show that the signer handled some opaque bytes, and would leave the signature exposed for any relaying party to strip and replace.
code
json · 7 lines{
"alg": "RSA-OAEP-256",
"enc": "A256GCM",
"cty": "JWT",
"typ": "JWT",
"kid": "rp-2026-06"
}go deeper
Recall that a nested JWT means one token inside another, and that it exists because signing and encrypting give different guarantees.
Explain the mechanics: a compact JWS becomes the plaintext of a JWE, the outer header sets cty to JWT, and the recipient decrypts before verifying.
Justify the ordering with the two concrete failures of encrypt-then-sign — a signature that attests only to opaque bytes, and an outer signature a relayer can strip and replace.
Own the decision to nest at all: it doubles key management and token size, so argue when confidentiality plus provable origin justifies that against keeping the sensitive data server-side.
## The definition RFC 7519 defines a **Nested JWT** as a JWT in which the payload is itself a JWT. The signal is the `cty` (content type) header parameter with the value `JWT` on the outer token. Without it a recipient that successfully decrypts a JWE has a byte string and no standard way to know it should parse it as another token; with it, the processing rule is unambiguous. In practice the nesting is a JWS inside a JWE. The issuer signs the claims, producing a three-segment compact JWS; that entire string becomes the plaintext of a JWE, producing a five-segment outer token. The recipient reverses it: decrypt the outer JWE, see `cty` of `JWT`, parse the plaintext as a JWS, verify its signature, and only then read the claims. ## Why one container is not enough The two containers give genuinely different guarantees. A JWS gives integrity and, with an asymmetric algorithm, origin: you learn that the holder of a specific private key produced these claims and that nobody altered them. It gives no confidentiality — the claims are readable by anyone holding the token. A JWE gives confidentiality of the claims and integrity of the ciphertext. What it usually does *not* give is origin. Under `RSA-OAEP-256` or `ECDH-ES`, the content key is protected using the recipient's *public* key material, which by definition is not secret. Any party that can fetch that public key can mint a syntactically perfect JWE full of claims of its choosing, addressed to that recipient. Only a symmetric key-management algorithm such as `dir` or `A256KW` implies the sender knew a shared secret — and even then the property is shared-key authentication with no non-repudiation, since either party could have produced it. So when a token must be both unreadable to intermediaries and provably issued by a particular authority, you need a signature *and* encryption. That is the nested JWT. ## Why the order is sign, then encrypt RFC 7519 states the ordering preference explicitly, and the reasoning is worth being able to reproduce. First, a signature over ciphertext says nothing about the plaintext. If you encrypt and then sign, the signer is attesting that it handled some opaque blob — it may never have seen, or agreed with, the claims inside. A verifier that treats such a signature as an endorsement of the claims is drawing a conclusion the construction does not support. Second, the outer layer of a token is the visible one. Encrypt-then-sign leaves the signature in the clear on the outside, where any party that relays the token can remove it and attach its own over the same ciphertext, claiming authorship of a message it cannot read. Sign-then-encrypt puts the signature inside the envelope, so it reaches the recipient bound to the claims and inaccessible to anyone in between. Third, sign-then-encrypt keeps the identity of the signer out of the clear. The signature and the `kid` that identifies the signing key are metadata; leaving them outside leaks who vouched for a message whose contents you deliberately hid. ## What it costs Nesting doubles the cryptographic work and lengthens the token substantially, since the inner JWS is Base64url text that is then encrypted and Base64url-encoded again. It also doubles the key management: signing keys published for verification *and* a current encryption public key held by the issuer for every recipient. Debugging becomes a two-step process requiring the recipient's private key, which typically means an incident-time tool rather than reading the token in a log. Because of that cost, nesting is reserved for the cases that genuinely need both properties: tokens relayed through parties that must not read them, front-channel flows where the token traverses a user agent, and cross-organisation assertions where the claims are sensitive and the issuer must be provable. ## The processing rule to state out loud Decrypt, check `cty`, verify the inner signature, then validate claims. Never read claims out of a decrypted payload before verifying its signature — decryption succeeded means the token was addressed to you, not that it came from someone you trust.
- In what order does a recipient process a nested JWT?Decrypt the outer JWE with the key selected by its header, read `cty` to learn the plaintext is a JWT, parse the inner JWS, verify its signature against the issuer's key, and only then read and validate the claims. Successful decryption means the token was addressed to you, never that it came from a party you trust.
- When does a bare JWE, with no nested signature, actually carry an origin guarantee?Only when key management is symmetric — `dir` or a key-wrapping algorithm such as `A256KW` — because producing the token then required a shared secret. Even that is shared-key authentication with no non-repudiation: either holder of the secret could have created it, so it cannot settle a dispute about who did.
Sign the letter, then seal it in the envelope. Signing the envelope instead proves only that someone handled a sealed packet, and leaves the signature outside where anyone in the chain can peel it off.
saying these in an interview costs you the question
- Assumes a JWE proves who issued the token
- Signs the ciphertext instead of the claims
- Omits cty so the recipient cannot parse the plaintext
- Reads decrypted claims before verifying the inner signature
- Nests routinely, ignoring the size and key-management cost