JWT-Struktur

Drei Segmente, zwei Punkte

Die kompakte Serialisierung ist header.payload.signature – jedes Segment separat Base64url-kodiert, die Punkte als reine Trennzeichen. Die Kodierung ist bewusst ohne Padding, sodass ein Token nur Buchstaben, Ziffern, Binde- und Unterstriche enthält: sicher in URLs, Headern und Cookies, ganz ohne Escaping. Die ersten beiden Segmente zu dekodieren ist kein Hack – es ist der vorgesehene Weg, ein Token zu untersuchen; im dritten Segment findet die Verifizierung statt.

Ein echtes Token, über das eine Signatur gerechnet wurde, dekodiert sich exakt so:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwczovL2F1dGguZXhhbXBsZS5jb20iLCJzdWIiOiJ1c2VyXzg0OTIiLCJhdWQiOiJhcGkuZXhhbXBsZS5jb20iLCJpYXQiOjE3NjcyMjU2MDAsImV4cCI6MTc2NzMxMjAwMCwianRpIjoiYjBmNmMyZDQtNGU3YS00YzFmLTlhMmItM2Q1ZTdmOWExYzNlIn0.iDPqw4BRxZtM064Y3EH83XLB0cgEjbj5snSXeM846VY

{"alg":"HS256","typ":"JWT"}

{"iss":"https://auth.example.com","sub":"user_8492",
 "aud":"api.example.com","iat":1767225600,
 "exp":1767312000,
 "jti":"b0f6c2d4-4e7a-4c1f-9a2b-3d5e7f9a1c3e"}

Der Header: das Inhaltsverzeichnis des Tokens

Der Header ist ein kleines JSON-Objekt – formal das JWS Protected Header. Zwei Felder erledigen fast die gesamte Arbeit: alg nennt den Signaturalgorithmus, typ hält den Medientyp fest, üblicherweise JWT. Ein drittes, kid (key ID), zeigt dem Prüfer den richtigen Schlüssel, wenn ein Aussteller mehrere veröffentlicht. Der Header wird signiert, aber nie verschlüsselt, und er wird erst vertraut, nachdem die Signatur verifiziert wurde – bis dahin ist alg eine Behauptung, kein Fakt.

Der Payload: registrierte Claims und was jeder verspricht

Der Payload ist ein JSON-Objekt aus Claims. Sieben sind in RFC 7519 mit präziser, interoperabler Bedeutung registriert; alles andere bleibt privat zwischen Aussteller und Zielgruppe. Zeitangaben sind NumericDate-Werte – Sekunden seit der Unix-Epoche, nicht Millisekunden – und die Zeit-Claims sind Hinweise für den Prüfer: Sie zu kontrollieren ist Aufgabe des Prüfers, nicht etwas, was das Format erzwingt.

Die Signatur: HS256, RS256 und wie die Verifizierung funktioniert

Die Signatur wird über die Signierungseingabe gerechnet – den kodierten Header, einen Punkt, den kodierten Payload – und zwar mit dem Algorithmus, den der Header nennt. HS256 ist HMAC-SHA256 mit einem geteilten Geheimnis: schnell und symmetrisch, aber nur passend, wenn Unterzeichner und alle Prüfer eine Vertrauensdomäne bilden, denn jeder, der das Geheimnis besitzt, kann Token ausstellen. RS256 ist RSA: Der Aussteller signiert mit einem privaten Schlüssel, und jeder – auch ein Browser – kann mit dem veröffentlichten öffentlichen Schlüssel verifizieren. Genau das macht RS256 zum Standard für föderierte Protokolle wie OAuth 2.0 und OpenID Connect.

Die Verifizierung rechnet die Signatur neu und vergleicht. Das ist der gesamte Mechanismus – und deshalb entscheidet allein der alg-Header, wie die Prüfung abläuft. Bibliotheken haben sich nach den Algorithmus-Verwechslungsangriffen der frühen 2010er Jahre gehärtet: Ein Token, das alg none behauptet, oder ein RS256-Token, das als HS256 wiedergegeben wird und den öffentlichen Schlüssel als HMAC-Geheimnis benutzt, verifiziert nur noch bei Prüfern, die ihren erwarteten Algorithmus nicht festschreiben.

HS256: HMAC-SHA256(secret, header + '.' + payload)
       Signierer und Prüfer teilen das Secret

RS256: RSA-SHA256(private key, header + '.' + payload)
       der Aussteller signiert; jeder prüft mit dem öffentlichen Schlüssel

Legen Sie den erwarteten Algorithmus pro Aussteller fest.
Leiten Sie ihn nie allein aus dem Header des Tokens ab.
Akzeptieren Sie niemals alg: none.

Signiert, nicht versiegelt: was die Signatur nicht leistet

Die Signatur beweist, dass das Token von demjenigen ausgestellt wurde, der den Schlüssel besitzt, und seitdem nicht verändert wurde – Integrität und Authentizität. Vertraulichkeit bietet sie null: Base64url ist eine Kodierung, und der Payload ist für jeden lesbar, der das Token zu sehen bekommt – auch für Browser-Erweiterungen, für Proxies, wenn Token in URLs unterwegs sind, und für Log-Sammler. Daraus ergeben sich die dauerhaften Regeln: Niemals Geheimnisse in einen JWT-Payload, niemals Token in URLs und jede dekodierte Claim als Daten behandeln, nicht als Entscheidung.

Der letzte Punkt ist die Falle auf der Client-Seite. Ein Browser kann ein Token dekodieren und exp oder sub lesen – aber er kann das Token nicht wirklich verifizieren, denn er besitzt den Schlüssel des Ausstellers nicht: Bei HS256 darf das Geheimnis den Browser überhaupt nie erreichen, und bei RS256 beweist eine clientseitige Prüfung nichts darüber, was der Inhaber aufrufen darf. Clients dürfen Token für die Darstellung untersuchen – einen Namen anzeigen, vor Ablauf warnen –, aber der Server muss die Signatur und jede Claim bei jeder Anfrage verifizieren. Untersuchung ist keine Verifizierung, und lesbar ist nicht autorisiert.

Token sicher untersuchen – der praktische Ablauf

Ein disziplinierter Prüfzyklus dauert Sekunden: Header und Payload dekodieren, exp und nbf mit der Uhr abgleichen, bestätigen, dass iss und aud den Erwartungen entsprechen – und erst dann, auf dem Server, die Signatur mit einem festgeschriebenen Algorithmus und dem richtigen Schlüssel verifizieren. Alles außer der letzten Verifizierung ist reine Textverarbeitung; deshalb ist ein Decoder, der vollständig in Ihrem Browser läuft, das richtige Werkzeug: Echte Token sind Bearer-Zugangsdaten, und Zugangsdaten gehören in Tabs, die Sie kontrollieren – nicht auf Websites, die sie weiterleiten könnten.

Bedenken Sie, was die Struktur nicht leisten kann: Widerruf – jti-basierte Sperrlisten müssen serverseitig aufgebaut und geprüft werden; Vertraulichkeit – brauchen Sie verschlüsselte Token, verwenden Sie JWE; und Vertrauen – ein strukturell perfektes Token von einem Aussteller, den Sie nie konfiguriert haben, ist wertlos. Die Struktur sagt Ihnen, was versprochen wurde; nur die Verifizierung sagt Ihnen, dass das Versprechen intakt ist.