Header (JWT/JWS)

Der Header eines JWT (oder JWS) ist das erste durch Punkt getrennte Segment, ein base64url-codiertes JSON-Objekt, das die Signatureigenschaften des Tokens beschreibt. Decodiert man es, erhält man ein kleines JSON-Objekt mit typischerweise 2–5 Feldern.

Standard-Header-Felder (RFC 7515 §4):

• alg — Algorithmus. Erforderlich. z. B. HS256, RS256, ES256 oder none.
• typ — Typ. Konventionsgemäß "JWT", wenn die Payload ein JWT-Claims-Set ist.
• kid — Schlüssel-ID. Erlaubt es dem Empfänger, den richtigen Schlüssel aus einem Schlüsselsatz zu wählen, wenn der Aussteller Schlüssel rotiert.
• jwk / jku — eingebetteter JSON Web Key oder URL zu einem. Seltener; sicherheitskritisch, wenn verwendet.
• cty — Content-Type. Wird verwendet, wenn die Payload eine verschachtelte JOSE-Struktur ist (z. B. ein JWE in einem JWS).

Durchgerechnetes Beispiel. Ein Header, der zu Folgendem decodiert:

{ "alg": "RS256", "typ": "JWT", "kid": "2024-q1-key" }

deklariert, dass das Token mit RS256 (RSA + SHA-256) signiert ist, ein JWT ist (die Payload also ein Claims-Set) und mit dem durch 2024-q1-key identifizierten Schlüssel im Schlüsselverzeichnis des Ausstellers signiert wurde.

Wichtiger Sicherheitshinweis: Vertrauen Sie niemals dem alg-Feld allein. Prüfen Sie, dass der Algorithmus zu dem passt, wofür Ihr Schlüssel geeignet ist. Der alg-Confusion-Angriff funktioniert, indem ein mit HS256 (HMAC) signiertes Token übergeben wird, das Ihren öffentlichen RSA-Schlüssel als HMAC-Geheimnis verwendet – vertraut Ihr Prüfer blind dem alg-Feld, akzeptiert er die Fälschung.

Die kompakte base64url-Codierung des Headers macht ihn menschlich inspizierbar: Fügt man das erste durch Punkt getrennte Segment eines beliebigen JWT in einen base64url-Decoder ein, offenbart das innerhalb von Sekunden den Algorithmus und die Schlüsselreferenz. Das ist der Einstiegspunkt jeder JWT-Debugging-Sitzung – decodiert der Header zu Müll, ist das Token fehlerhaft; decodiert er zu einem JSON-Objekt, das Sie nicht wiedererkennen, hat der Aussteller etwas geändert.

Wann und warum es zählt

Der JWT-Header zählt jedes Mal, wenn ein Dienst ein Token prüft. Die klassische CVE-Kette: Ein Prüfer akzeptiert das alg-Feld für bare Münze und lässt ein Token, das "alg": "none" angibt, ganz ohne Signaturprüfung passieren. Dieser Fehler wurde noch 2015 in Produktionsbibliotheken ausgeliefert (CVE-2015-9235, betraf Auth0s node-jsonwebtoken). Die Abwehr besteht darin, im Prüfaufruf den genauen Algorithmus zu erzwingen, den die Bibliothek akzeptieren soll – z. B. jwt.verify(token, key, { algorithms: ['RS256'] }) – und niemals dem Header die Wahl des Algorithmus zu überlassen. Eine zweite Fehlerklasse, der alg-Confusion-Angriff, nutzt Bibliotheken aus, die HMAC vs. RSA anhand des Headers automatisch wählen: Der Angreifer übergibt dem Prüfer ein Token, das HS256 angibt, signiert es aber mit dem (veröffentlichten) öffentlichen RSA-Schlüssel als HMAC-Geheimnis. Der Prüfer validiert gegen den öffentlichen Schlüssel und akzeptiert die Fälschung. Beide Fehler sind Header-Vertrauensprobleme. Bei neuen JWT-Integrationen prüfen Sie den Verifizierungsaufruf und stellen sicher, dass er den Algorithmus festpinnt. Referenz: OWASP – JSON Web Token cheat sheet.

Das kid-Header-Feld bei der Schlüsselrotation in Produktion: In jedem realen System, das Tokens im großen Maßstab ausstellt, muss der Signaturschlüssel regelmäßig rotiert werden – alle 90 Tage ist eine gängige Richtlinie. Das kid-Feld erlaubt es dem Aussteller, mehrere Schlüssel gleichzeitig zu veröffentlichen (alte Schlüssel für noch laufende Tokens, neue Schlüssel für frische Ausstellungen), und der Prüfer wählt den richtigen aus einem JWKS-Endpunkt. Das Standard-Rotationsmuster: den neuen Schlüssel im JWKS ankündigen, während noch mit dem alten signiert wird, eine Token-Lebensdauer warten, die Ausstellung auf den neuen Schlüssel umstellen, eine weitere Lebensdauer warten, dann den alten Schlüssel aus dem JWKS entfernen. Das kid-Feld ist das, was dies elegant macht – ohne es erfordert Schlüsselrotation eine synchronisierte Stichtagsumstellung.

Wie der jku- / x5u-Angriffsvektor aussieht: Manche Implementierungen erlauben es dem Header, auf eine beliebige URL zu verweisen, wo der Prüfschlüssel angeblich liegt. Ein Angreifer, der jku auf eine von ihm kontrollierte URL setzt, kann jeden beliebigen Schlüssel präsentieren, und der Prüfer wird ihn verwenden. Die moderne Empfehlung (RFC 8725, JOSE-Best-Practices) lautet, jku/x5u entweder ganz abzulehnen oder eine Allow-Liste vertrauenswürdiger URLs zu erzwingen. Neue JWT-Integrationen sollten sich nicht auf eine header-gesteuerte Schlüsselposition verlassen. Referenz: RFC 8725 – JSON Web Token Best Current Practices.