JWT-Aufbau: die drei Base64URL-Teile

Drei Teile, getrennt durch Punkte

Ein JWT sieht für das Auge wie ein langer, zufälliger String aus - z.B. eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ1c2VyXzQyIn0.abc.... Tatsächlich sind das drei base64url-encodete Teile, getrennt durch Punkte: Header, Payload und Signature.

1. Header - die "Wie"-Frage

Der Header (JOSE Header, RFC 7515 §4) sagt dem Verifier, wie er das Token prüfen soll. Minimal:

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

Felder im Detail:

• alg (Pflicht): der Signatur-Algorithmus, z.B. HS256, RS256, ES256, EdDSA. Erlaubte Werte stehen in RFC 7518 (JWA).
• typ (optional): meist "JWT". Bei verketteten Tokens auch "at+jwt" oder "id+jwt".
• kid (Key ID, optional): identifiziert, welcher Key des Issuers verwendet wurde - wichtig für Key-Rotation.
• jku, x5c, x5t: selten, beziehen sich auf JWKS-URLs oder X.509-Zertifikate.

Wichtig: Der Header ist vom Token-Inhaber veränderbar. Ein Verifier darf alg NIE blind glauben - er muss eine eigene Whitelist erlaubter Algorithmen führen und nur dagegen prüfen.

2. Payload - die Claims

Der Payload ist ein JSON-Objekt mit "Claims" - Aussagen über das Subject. RFC 7519 unterscheidet drei Typen:

• Registered Claims (in IANA-Registry standardisiert): iss, sub, aud, exp, iat, nbf, jti
• Public Claims: frei wählbar, aber idealerweise in der IANA-Registry für JWT Claims angemeldet (kollisionssicher). Beispiele: email, name, picture (aus OIDC).
• Private Claims: custom-Felder zwischen einem konkreten Issuer und Consumer abgesprochen. Beispiele: role, tenant_id, permissions.

Sicherheitshinweis: Der Payload ist nur base64url-encoded, NICHT verschlüsselt. Jeder mit Token-Zugriff kann ihn lesen. Niemals Passwörter, vollständige Adressdaten oder andere sensitive Information im Payload speichern.

3. Signature - die "Stimmt das"-Antwort

Die Signature ist das Ergebnis von sign(alg, key, base64url(header) + "." + base64url(payload)). Bei HS256: HMAC-SHA256 mit dem Shared Secret. Bei RS256: RSA-PKCS1v1.5 mit dem Private Key. Die Signature wird ebenfalls base64url-encoded angehängt.

Der Verifier rechnet den gleichen Schritt nach (mit Public Key oder Shared Secret) und vergleicht das Ergebnis mit der mitgelieferten Signatur. Stimmt sie nicht: Token wurde manipuliert oder mit falschem Key signiert.

Beispiel-Token im Detail

Token: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyXzQyIn0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

• Header (base64url-decoded): {"alg":"HS256","typ":"JWT"}
• Payload (base64url-decoded): {"sub":"user_42"}
• Signature: HMAC-SHA256("eyJhbGc...payload", "your-256-bit-secret")

Im jwtdecoder.de lässt sich der Token einfach einfügen - alle drei Teile werden als JSON dargestellt, Zeitstempel werden human-readable formatiert, und mit dem Secret kann die Signatur verifiziert werden.

Häufige Fragen

Warum base64url und nicht klassisches base64? Klassisches base64 verwendet die Zeichen +, / und = - alle drei haben in URLs Spezialbedeutungen. Base64url (RFC 4648 §5) ersetzt sie durch -, _ und lässt das Padding weg.

Wie groß darf ein JWT werden? Praktische Obergrenze ~1 KB. Manche HTTP-Server limitieren Header auf 4-8 KB total, das Token konkurriert dort mit Cookies und anderen Headern. Token über 2 KB sind ein Warnsignal - meist sind zu viele Claims drin.

Mehr zum Signatur-Algorithmus und zu den Standard-Claims in den verlinkten Artikeln.