Uma chave de criptografia de conteúdo (CEK) aleatória criptografa o payload com um AEAD como A256GCM ou A128CBC-HS256 (enc); a CEK chega ao destinatário pelo algoritmo de gerenciamento de chaves (alg): RSA-OAEP-256, ECDH-ES (acordo direto, com a parte da chave criptografada vazia) ou ECDH-ES+A256KW, A256KW com uma chave compartilhada ou dir para uma CEK pré-compartilhada. O cabeçalho protegido entra como dados associados do AEAD, por isso não pode ser alterado.
Um JWE garante confidencialidade em relação ao destinatário, mas, com ECDH-ES ou RSA-OAEP, nenhuma autenticação do remetente: qualquer pessoa com a chave pública pode criar um. Os JWTs aninhados primeiro assinam e depois criptografam o JWT assinado, com cty definido como JWT. Armadilhas conhecidas são pontos de curva inválida em ECDH-ES (valide o epk), PBES2 com contagens de iteração enormes como vetor de negação de serviço e o padding oracle do RSA1_5; a RFC 8725 lista as mitigações.
A maioria das APIs nunca precisa de JWE, porque o TLS já protege o canal; o JWE é útil para tokens que passam por intermediários não confiáveis ou que ficam armazenados nos clientes. O inspetor de JWE mostra o cabeçalho e a estrutura sem descriptografar.