JWE

JWE (JSON Web Encryption, RFC 7516) ist das Verschlüsselungs-Framework in der JOSE-Familie (JSON Object Signing and Encryption), Schwester von JWS. Während JWS eine Nutzlast signiert (sie bleibt lesbar, aber manipulationsgeschützt), verschlüsselt JWE die Nutzlast (ihr Inhalt bleibt vertraulich).

Ein JWE-Token in kompakter Serialisierung hat fünf durch Punkte getrennte Segmente statt der drei eines JWT:

1. Header – JSON, das die Verschlüsselungsalgorithmen deklariert.
2. Verschlüsselter Content Encryption Key (CEK) – der für die Nutzlast verwendete symmetrische Schlüssel, der selbst mit dem Schlüssel des Empfängers verschlüsselt ist.
3. Initialisierungsvektor (IV) – zufällige Nonce pro Verschlüsselung.
4. Geheimtext – die tatsächlich verschlüsselte Nutzlast.
5. Authentifizierungs-Tag – für AEAD-Modi; bestätigt, dass der Geheimtext nicht manipuliert wurde.

JWE verwendet ein Hybridverfahren: Ein symmetrischer Schlüssel (der CEK) verschlüsselt die Nutzlast (weil symmetrische Kryptografie schnell ist), dann verschlüsselt ein asymmetrischer Schlüssel den CEK (weil asymmetrische Kryptografie der einzige Weg ist, Schlüssel ohne gemeinsames Geheimnis austauschbar zu halten). Standardalgorithmen: RSA-OAEP für den Schlüssel-Wrap, A256GCM für die Nutzlastverschlüsselung.

Wann JWE statt JWT: Die meisten Authentifizierungssysteme verwenden JWT (signiert, aber nicht verschlüsselt), weil die Claims nicht geheim sind – ein Token mit „sub: user_123, exp: …“ ist unbedenklich lesbar. Verwenden Sie JWE, wenn das Token wirklich sensible Nutzlast enthält (medizinische Unterlagen, Finanzdetails, rein interne Routingdaten) und Sie nicht garantieren können, dass Zwischenstellen sie nicht einsehen. Die meisten modernen Systeme bevorzugen es, sensible Daten auf dem Server zu halten und stattdessen eine kurze, undurchsichtige Session-ID zu verwenden – einfacher als JWE.

Durchgerechnetes Beispiel

Ein Token-Aussteller muss eine Referenz auf eine medizinische Unterlage über den Browser an einen nachgelagerten Dienst senden, doch der Browser darf sie nicht lesen können. Der Aussteller erstellt ein JWE: Header {"alg":"RSA-OAEP-256","enc":"A256GCM","cty":"JWT","kid":"recipient-2026"}, Nutzlast {"patient_id":"P-12345","record_id":"R-78910"}. Der Aussteller erzeugt einen zufälligen 256-Bit-CEK, verschlüsselt die Nutzlast mit AES-256-GCM unter diesem Schlüssel (erzeugt Geheimtext + 128-Bit-Authentifizierungs-Tag) und verschlüsselt den CEK selbst unter dem öffentlichen RSA-Schlüssel des Empfängers. Die Ausgabe sind fünf base64url-kodierte, durch Punkte verbundene Segmente – insgesamt etwa 600–800 Byte. Der Empfänger entpackt in umgekehrter Reihenfolge: den CEK mit seinem privaten Schlüssel per RSA entschlüsseln, die Nutzlast mit dem CEK per AES-GCM entschlüsseln, prüfen, ob das Auth-Tag stimmt. Jede Manipulation an einem der fünf Segmente lässt die Auth-Tag-Prüfung scheitern, und der Empfänger weist das Token zurück. Der Browser, der das JWE dazwischen transportiert, sieht nur undurchsichtiges Base64 – die Patienten-/Datensatz-IDs sind unzugänglich.

Wann und warum es zählt

JWE zählt immer dann, wenn ein Token vertrauenswürdige Grenzen mit vertraulichen Claims durchqueren muss – Patientendaten, Finanz-Routingdetails, interne Nutzerkennungen – und die Architektur ein Token statt einer serverseitigen Session verwenden muss. Der zu vermeidende Fehler ist, zuerst zu JWE zu greifen, wenn eine einfachere Architektur ausreicht: Die meisten Authentifizierungsflüsse sind mit signierten JWTs besser bedient, die nur Referenzen enthalten (eine Nutzer-ID, eine Session-ID), die Zwischenstellen harmlos sehen können, während die sensiblen Daten in der Datenbank des Ausstellers bleiben. Verwenden Sie JWE, wenn Zwischenstellen betrieblich das Token halten müssen, aber vertraglich oder rechtlich daran gehindert sind, es zu lesen – föderiertes SSO über Organisationen hinweg, Austausch von Gesundheitsdaten zwischen Anbietern, einige Open-Banking-PSD2-Flüsse. Der zweite Fehler ist eine unpassende Algorithmuswahl: RSA-OAEP mit SHA-1 ist veraltet, RSA-OAEP-256 ist die aktuelle Empfehlung; A128CBC-HS256 ist noch akzeptabel, doch A256GCM wird für neue Implementierungen bevorzugt. Quelle: RFC 7518 – JSON Web Algorithms.

Verschachteltes JOSE – erst signieren, dann verschlüsseln: Für Token, die sowohl Authentizität (nachweisbare Herkunft) als auch Vertraulichkeit benötigen, ist das Standardmuster signiert-dann-verschlüsselt: Die Nutzlast wird zunächst in ein JWS verpackt, dann wird das gesamte JWS zur Nutzlast eines JWE. Das Headerfeld cty: "JWT" im äußeren JWE signalisiert dem Parser, dass der entschlüsselte Inhalt selbst ein zu prüfendes JOSE-Token ist. Die umgekehrte Reihenfolge (erst verschlüsseln, dann signieren) ist weniger sicher, weil die Signatur über Geheimtext erfolgen würde, der über Empfänger hinweg wiedergespielt werden könnte. Die meisten Unternehmens-SSO-Plattformen, die JWE verwenden (Microsoft-Azure-AD-Föderationstoken, einige Banking-APIs), liefern signiert-dann-verschlüsselt als Standard aus. Quelle: RFC 7516 – JSON Web Encryption.