JWS

JWS (JSON Web Signature, RFC 7515) ist das kryptografische Signatur-Framework, auf dem JWT aufbaut. Ein JWS besteht aus drei durch Punkte verbundenen Teilen: header.payload.signature, jedes Segment base64url-kodiert. Der Header ist JSON, das den Algorithmus deklariert; die Nutzlast können beliebige Bytes sein (typischerweise, aber nicht zwingend JSON); die Signatur wird über den durch Punkte verbundenen Header und die Nutzlast mit dem deklarierten Algorithmus berechnet.

Die Beziehung zu JWT: Jedes JWT ist ein JWS, dessen Nutzlast ein JSON-Objekt aus Claims sein muss. Doch JWS selbst ist allgemeiner – die Nutzlast kann rohe Binärdaten, ein XML-Dokument oder jede andere Bytefolge sein. Wenn Sie ein dreiteiliges, durch Punkte getrenntes Token sehen, dessen mittleres Segment sich nicht zu JSON base64-dekodiert, handelt es sich um ein JWS, nicht um ein JWT.

Gängige Algorithmen: HS256 (HMAC-SHA256, symmetrischer Schlüssel), RS256 (RSA-SHA256, asymmetrisch), ES256 (ECDSA-P256-SHA256, asymmetrisch). Der gefährliche Algorithmus „none“ bedeutet „keine Signatur“ – laut Spezifikation zulässig, aber serverseitig immer abzulehnen. Produktive Prüfer sollten zudem explizit prüfen, dass der im Header deklarierte Algorithmus dem für den Schlüssel erwarteten Algorithmus entspricht.

JWS hat zwei Serialisierungen: kompakt (das durch Punkte getrennte Format, das JWT verwendet) und JSON (eine JSON-Hülle, die dieselben drei Teile umschließt und mehrere Signaturen unterstützt). Die kompakte Form ist das, was nahezu jede API verwendet; die JSON-Form ist außerhalb spezifischer Protokolle selten.

Durchgerechnetes Beispiel

Nehmen wir das JWS eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ1c2VyXzEyMyJ9.4Adcj3UFYzPUVaHwte4eBI6vsjOvpz0yiwIM0F7sjuk. Dekodieren Sie den Header (erstes Segment): {"alg":"HS256"} – HMAC-SHA256-Signatur. Dekodieren Sie die Nutzlast (zweites Segment): {"sub":"user_123"}. Die Signatur (drittes Segment) ist der HMAC-SHA256 von eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ1c2VyXzEyMyJ9 unter Verwendung des gemeinsamen geheimen Schlüssels. Der Prüfer rekonstruiert den HMAC und vergleicht ihn mittels konstanter Vergleichszeit; bei Abweichung → ablehnen. Vergleichen wir nun mit RS256: gleiche Struktur, doch die Signatur ist RSA-SHA256, der Aussteller signiert mit einem privaten Schlüssel und Prüfer kontrollieren mit dem öffentlichen Schlüssel. Die Token-Bytes sind länger (RSA-Signaturen sind ~342 Base64-Zeichen für einen 2048-Bit-Schlüssel gegenüber 43 bei HMAC-SHA256), doch die Validierungssemantik ist aus Sicht des Aufrufers identisch.

Wann und warum es zählt

JWS zählt jedes Mal, wenn ein Dienst ein JWT ausstellt, überträgt oder annimmt – was 2026 die meisten APIs sind. Die Fehler, die im letzten Jahrzehnt wiederholt CVEs hervorgebracht haben: (1) die Signatur überhaupt nicht zu validieren und die Nutzlast als vertrauenswürdig zu behandeln, nur weil sie sich als JSON parsen ließ; (2) alg: none zu akzeptieren, was die Signatur vollständig entfernt; (3) jeden vom Token deklarierten Algorithmus zu akzeptieren, was den HS256-mit-RSA-öffentlichem-Schlüssel-Verwechslungsangriff ermöglicht; (4) exp nicht zu validieren und so das Wiedereinspielen längst abgelaufener Token zu erlauben; (5) iss und aud nicht zu validieren und Token zu akzeptieren, die für völlig andere Dienste ausgestellt wurden. Die defensive Grundlinie: den erwarteten Algorithmus im Prüfaufruf festlegen, den Prüfschlüssel aus einer vertrauenswürdigen Quelle beziehen (typischerweise eine zur Konfigurationszeit freigegebene JWKS-URL, nicht der tokeneigene jku) und exp, iss und aud als separate Prüfungen nach der Signatur validieren. Quelle: RFC 8725 – JWT Best Current Practices.

Warum der Algorithmus-Verwechslungsangriff immer noch in CVEs auftaucht: Eine langlebige Familie von JWS-Schwachstellen betrifft einen Server, der die JWT-Bibliothek fragt „ist dieses Token gültig?“ und die Bibliothek den Prüfalgorithmus aus dem tokeneigenen Header wählen lässt. Ein Angreifer, der den öffentlichen RSA-Schlüssel des Servers kennt (der definitionsgemäß öffentlich ist), kann ein Token erstellen, das mit HMAC-SHA256 unter Verwendung der Bytes des öffentlichen RSA-Schlüssels als HMAC-Geheimnis signiert ist, im Header alg: HS256 setzen, und viele Bibliotheken werden es verifizieren. Die Gegenmaßnahme besteht darin, die Prüfung auf den erwarteten Algorithmus festzulegen – ihn als explizites Argument an den Verify-Aufruf zu übergeben, statt das Token ihn bestimmen zu lassen. Die Offenlegung dieses Angriffs 2015 gegen mehrere große Bibliotheken (Nodes jsonwebtoken, Pythons pyjwt, mehrere Java-Implementierungen) ist die klassische Warngeschichte.

Detached JWS – wenn die Nutzlast zu groß zum Einbetten ist: RFC 7797 definiert einen „Detached-Payload“-Modus, bei dem das mittlere Segment leer ist und die Nutzlast außerhalb des Bandes übertragen wird (z. B. als HTTP-Body, während das JWS in einem Header sitzt). So signieren einige Finanz-APIs große Anfrage-Bodies, ohne Megabytes an JSON erneut base64-zu-kodieren. Die Signatur wird weiterhin über die ursprünglichen Nutzlast-Bytes berechnet; nur das Übertragungsformat ändert sich. Quelle: RFC 7515 – JSON Web Signature.