skip to content

In JOSE, when would you use the JSON serialization of a JWS instead of the compact one?

level: middleimportance: nice to knowfreq 25%

answer

  1. One signature versus several
  2. Where would unprotected parameters live
  3. Does it fit in an Authorization header
  4. payload plus a signatures array
  5. Not every JWS is a JWT

basics

~20 s

Use the JSON serialization when you need several signatures over one payload, unprotected header parameters, or a detached payload. Compact serialization supports exactly one signature and only the protected header, but it is URL-safe and is the only form RFC 7519 permits for a JWT.

solid answer

~40 s

Compact serialization is the dot-separated string everyone recognises: one payload, one signature, protected header only, safe to drop into an `Authorization` header or a query string. RFC 7515 also defines a **JSON serialization**, a JSON object with a `payload` member and a `signatures` array whose entries each carry `protected`, an optional unprotected `header`, and `signature`. That form supports multiple signers over the same payload, header parameters that are deliberately outside the signature, and — by omitting the `payload` member — a detached payload signed out of band. A flattened variant lifts a single signature to the top level. The catch worth knowing: RFC 7519 says a JWT is always the *compact* serialization of a JWS or JWE, so a multi-signature JSON-serialized object is a valid JWS but is not a JWT.

code

json · 14 lines
json
{
  "payload": "eyJzdWIiOiIxMjM0In0",
  "signatures": [
    {
      "protected": "eyJhbGciOiJSUzI1NiIsImtpZCI6ImEifQ",
      "header": { "role": "originator" },
      "signature": "MRjdkly7_-oTPTS3AXP4..."
    },
    {
      "protected": "eyJhbGciOiJFUzI1NiIsImtpZCI6ImIifQ",
      "signature": "pKfDLbHi4t9YQ2xk1Fzr..."
    }
  ]
}

go deeper

for a junior

Recall that the dot-separated string is the compact serialization and that JOSE also defines a JSON object form; you are unlikely to be pushed further.

for a middle

Explain the structural difference — a signatures array with protected and unprotected headers — and name the capabilities compact serialization cannot express.

for a senior

Show you know the JWT boundary: multi-signature or multi-recipient designs leave the JWT profile, which changes library support and validation reuse.

for a principal

Own the design call between a compact bearer credential and a signed document format, including who may countersign and what an unprotected header may safely carry.

## Two ways to write the same cryptographic object RFC 7515 defines two serializations for a JWS, and RFC 7516 mirrors them for a JWE. The cryptographic content is identical; what differs is the container syntax and therefore what it can express. **Compact serialization** is the familiar `header.payload.signature` string. Every segment is Base64url, which uses only characters that are safe in URLs, HTTP header values, and form fields. It is deliberately minimal: exactly one signature, exactly one recipient, and no place to put anything that is not covered by the signature. **JSON serialization** is a JSON object. For a JWS the general form has a `payload` member and a `signatures` array; each element holds `protected` (the Base64url-encoded header covered by the signature), an optional `header` member with unprotected parameters, and `signature`. A **flattened** form drops the array when there is only one signature and puts `protected`, `header`, and `signature` at the top level alongside `payload`. The JWE JSON serialization is analogous: `protected`, an optional `unprotected`, a `recipients` array whose elements carry a per-recipient `header` and `encrypted_key`, plus `iv`, `ciphertext`, `tag`, and optional `aad`. ## What the JSON form buys you **Multiple signatures over one payload.** A document can be signed by two parties, or by the same party under two algorithms during an algorithm migration, without duplicating the payload. Compact serialization cannot express this at all. **Multiple recipients for one JWE.** The `recipients` array lets the same ciphertext be decryptable by several parties: the content encryption key is wrapped once per recipient while the payload is encrypted once. **Unprotected headers.** Parameters in the `header` member are not covered by the signature or tag. That is useful for routing or bookkeeping metadata that an intermediary may legitimately rewrite — and it is a hazard, because anything there is attacker-modifiable and must never be trusted for a security decision. **Detached payload.** RFC 7515 describes omitting the `payload` member and transmitting the signed content separately — signing a large file or an HTTP body without embedding a second copy of it inside the signature object. ## What it costs A JSON-serialized JWS is not a compact string. It does not fit an `Authorization: Bearer` value, it is bulky, and it needs a JSON parse before any cryptographic step, which enlarges the pre-verification attack surface. Library support is also thinner: many JWT libraries implement only the compact form, so choosing JSON serialization commits you to a fuller JOSE implementation on every consumer. ## The JWT boundary This is the part interviewers use as a differentiator. RFC 7519 states that JWTs are always represented using the JWS Compact Serialization or the JWE Compact Serialization. So the relationship is one-directional: every JWT is a compactly serialized JWS or JWE, but not every JWS is a JWT. A JSON-serialized JWS with three signatures over an invoice is a perfectly valid, standards-conformant JWS — and calling it a JWT is wrong. That matters practically. If a design calls for multiple signers or multiple recipients, you have left the JWT profile and are doing general JOSE, which changes which libraries and which validation code you can reuse. ## Choosing in practice For bearer tokens on HTTP — access tokens, ID tokens, anything carried in a header or cookie — compact serialization is the answer, and there is no real debate. Reach for JSON serialization for signed *documents*: content that is stored or exchanged rather than presented as a credential, where countersigning, multi-party addressing, or detached signing is a real requirement. If none of those requirements is present, the JSON form is added complexity with no benefit.

  • What is a detached payload, and why would you sign one?
    The JSON serialization may omit the `payload` member entirely, with the signed content transmitted or stored separately. It avoids carrying a second Base64url copy of a large artefact inside the signature object — useful for signing files or HTTP bodies. Verifiers must be given exactly the same bytes out of band, or verification fails.
  • What is the risk of putting a parameter in the unprotected header member?
    Nothing covers it, so any party in the path can add, remove, or change it without invalidating the signature or the authentication tag. It is acceptable for routing hints and bookkeeping, but a security decision that reads an unprotected parameter is effectively taking instructions from an attacker.

saying these in an interview costs you the question

  • Calls a JSON-serialized JWS a JWT
  • Believes compact serialization can hold two signatures
  • Trusts unprotected header parameters for security decisions
  • Uses JSON serialization for HTTP bearer tokens
  • Thinks the two serializations differ cryptographically

context

resolving links…