skip to content

In a JWE, what do the JOSE header's alg and enc fields each specify?

level: middleimportance: should knowfreq 40%

answer

  1. Two operations, two header fields
  2. One key protects the claims, one delivers it
  3. Content encryption key, per token
  4. alg means something different than in a JWS
  5. dir leaves the second segment empty

basics

~20 s

In a JWE, alg names the key management algorithm that delivers the per-token content encryption key to the recipient, while enc names the authenticated encryption algorithm applied to the claims themselves. A JWS header has only alg, and there it names a signature algorithm.

solid answer

~50 s

A JWE always encrypts the payload under a freshly generated **content encryption key** (CEK). The header's `enc` parameter says which authenticated encryption algorithm the CEK is used with — values such as `A256GCM` or `A128CBC-HS256` from RFC 7518. The header's `alg` parameter says how that CEK reaches the recipient: `RSA-OAEP-256` wraps it under the recipient's RSA public key, `ECDH-ES` derives it from an ephemeral key agreement, `A256KW` wraps it under a shared symmetric key, and `dir` means there is no wrapped key at all — a pre-shared key *is* the CEK, so the encrypted-key segment is empty. The trap is assuming `alg` means the same thing it means in a JWS. In a JWS `alg` names a signature or MAC algorithm; in a JWE it never does, and a JWE with no nested signature carries no signature algorithm at all.

code

json · 6 lines
json
{
  "alg": "RSA-OAEP-256",
  "enc": "A256GCM",
  "kid": "rp-2026-06",
  "typ": "JWT"
}

go deeper

for a junior

Recall that a JWE header carries two algorithm names rather than one, and that the claims are ciphertext rather than readable JSON.

for a middle

Explain the split: enc protects the content under a per-token content encryption key, and alg describes how that key reaches the recipient.

for a senior

Be able to read a real header aloud and narrate the whole flow, including the cases where the encrypted-key segment is legitimately empty.

for a principal

Own the operational consequence: asymmetric key management means the issuer needs a current public key per audience, which is a distribution problem in the opposite direction from signature verification.

## Why a JWE needs two algorithm fields A JWS header describes one operation, so one `alg` value suffices. A JWE describes two: protecting the claims, and getting the key for that protection to the recipient. RFC 7516 therefore defines two header parameters, and both are mandatory in a JWE. Every JWE encrypts its payload under a **content encryption key**, or CEK — a symmetric key generated per token. The `enc` parameter identifies the algorithm the CEK is used with; the `alg` parameter identifies how the recipient comes to possess that CEK. ## The enc parameter: content encryption `enc` values come from the JWA registry (RFC 7518, section 5): `A128CBC-HS256`, `A192CBC-HS384`, `A256CBC-HS512`, `A128GCM`, `A192GCM`, and `A256GCM`. All of them are authenticated: they produce both ciphertext and an authentication tag, which occupy the fourth and fifth segments of the compact serialization. The initialization vector the algorithm needs sits in the third segment. One consequence worth stating: because the encryption is authenticated, a JWE detects tampering with its ciphertext. That is integrity of the *content*, and it is not the same as knowing who produced the token. ## The alg parameter: key management `alg` values come from RFC 7518 section 4 and fall into recognisable groups: - **Key wrapping under an asymmetric key** — `RSA-OAEP`, `RSA-OAEP-256`. The issuer generates a CEK, wraps it under the recipient's public key, and puts the wrapped bytes in the second segment. This is what lets an issuer encrypt to a recipient it has never shared a secret with. - **Key agreement** — `ECDH-ES` and its wrapping variants `ECDH-ES+A128KW`, `ECDH-ES+A192KW`, `ECDH-ES+A256KW`. With plain `ECDH-ES` the agreed value is the CEK directly and the encrypted-key segment is empty; the ephemeral public key travels in the header's `epk` parameter. - **Symmetric key wrapping** — `A128KW`, `A192KW`, `A256KW`, `A128GCMKW`, `A192GCMKW`, `A256GCMKW`. These require the two parties to already share a key. - **Password-based** — `PBES2-HS256+A128KW` and its siblings, for the cases where a human-chosen password is the input. - **Direct** — `dir`. A pre-shared symmetric key is used as the CEK itself, and the encrypted-key segment is the empty string. ## What the header does and does not protect The protected header is Base64url-encoded in the clear, because the recipient must read `alg`, `enc`, and any `kid` before it can do anything. It is not secret. It *is* bound into the encryption as additional authenticated data, so modifying it invalidates the authentication tag. That gives an important asymmetry: a JWE hides its claims but advertises which algorithms and which key identifier it used. The header may also carry `cty` (content type — set to `JWT` for a nested token), `typ`, `kid` to select the recipient key, and `zip` with the value `DEF` to compress the plaintext before encryption. Compression of secret data mixed with attacker-influenced data is discouraged by the JWT best-practices guidance in RFC 8725, so `zip` is rarely worth enabling. ## Reading a JWE header in an interview Given `{"alg":"RSA-OAEP-256","enc":"A256GCM","kid":"rp-2026-06"}` you should be able to narrate the whole flow: the issuer generated a random content encryption key, encrypted the claims with it under AES-256 in GCM mode, wrapped that key under the RSA public key identified by `rp-2026-06`, and shipped header, wrapped key, IV, ciphertext, and tag as five dot-separated segments. The recipient looks up its private key by `kid`, unwraps the CEK, and decrypts. ## The common mistakes The first is reading a JWE's `alg` as a signature algorithm and concluding the token is signed — it is not; a JWE contains no signature unless a JWS is nested inside it. The second is expecting `enc` on a JWS header, where it has no meaning. The third is assuming the encrypted-key segment is always populated; with `dir` and with plain `ECDH-ES` it is deliberately empty, and code that rejects an empty segment breaks on perfectly valid tokens.

  • Which JWE key-management algorithms leave the encrypted-key segment empty?
    `dir`, where a pre-shared symmetric key is used directly as the content encryption key, and plain `ECDH-ES`, where the agreed value is itself the content key and the ephemeral public key travels in the header's `epk` parameter. Both are valid tokens, so parsers must accept an empty second segment.
  • If the JWE header is not encrypted, what stops an attacker from editing it?
    The protected header is bound into the authenticated encryption as additional authenticated data. Changing any byte of it makes the authentication tag fail, so the recipient rejects the token. The header is public but not malleable — visibility and integrity are separate properties here.

saying these in an interview costs you the question

  • Reads a JWE's alg as a signature algorithm
  • Thinks a JWE is signed because it has alg
  • Expects enc to appear on a JWS header
  • Assumes the encrypted-key segment is never empty
  • Believes the JWE header itself is encrypted

context

resolving links…