Ein zufälliger Inhaltsschlüssel (Content Encryption Key, CEK) verschlüsselt die Payload mit einem AEAD wie A256GCM oder A128CBC-HS256 (enc); der CEK gelangt über den Schlüsselmanagement-Algorithmus (alg) zum Empfänger: RSA-OAEP-256, ECDH-ES (direkte Schlüsseleinigung, leerer Teil für den verschlüsselten Schlüssel) oder ECDH-ES+A256KW, A256KW mit einem gemeinsamen Schlüssel oder dir für einen vorab vereinbarten CEK. Der geschützte Header bildet die zusätzlichen Daten (Associated Data) des AEAD und lässt sich daher nicht verändern.
Ein JWE wahrt die Vertraulichkeit, sodass nur sein Empfänger den Inhalt lesen kann; mit ECDH-ES oder RSA-OAEP bietet es aber keine Authentifizierung des Absenders: Jeder, der den öffentlichen Schlüssel hat, kann eines erzeugen. Verschachtelte JWTs werden zuerst signiert, dann wird das signierte JWT verschlüsselt, wobei cty den Wert JWT erhält. Bekannte Stolperfallen sind Punkte auf ungültigen Kurven (Invalid Curve) in ECDH-ES (validiere epk), PBES2 mit riesigen Iterationszahlen als Denial-of-Service-Vektor und das Padding-Orakel bei RSA1_5; RFC 8725 nennt die Gegenmaßnahmen.
Die meisten APIs brauchen nie JWE, weil TLS den Kanal bereits schützt; nützlich ist es für Tokens, die über nicht vertrauenswürdige Zwischenstationen laufen oder von Clients gespeichert werden. Der JWE-Inspektor zeigt Header und Struktur, ohne zu entschlüsseln.