RFC 7519 · JSON Web Signature

Einführung in JWT

JSON Web Token (JWT) ist ein offener Standard (RFC 7519), um Claims als kompakte, URL-sichere Zeichenkette darzustellen. Er wird häufig mit OAuth 2.0 und OpenID Connect genutzt, das Format ist aber generisch: Jeder mit passendem Verifikationsmaterial kann die Signatur prüfen und über die Claims urteilen — innerhalb der Grenzen von Schlüssel- und Zeitverwaltung.

Diese Seite erklärt, wie ein JWT aufgebaut ist, wie man jeden Teil liest und welche Garantien Sie — und welche nicht — allein vom Token erwarten dürfen.

01

Kompakte Serialisierung und Kodierung

In der üblichen Form (JSON Web Signature, JWS) besteht ein JWT aus drei durch Punkte getrennten Segmenten: Header, Payload und Signatur. Die ersten beiden Segmente sind JSON-Objekte in Base64URL (nicht klassisches Base64): Padding fehlt oft, URL-sichere Zeichen ermöglichen den Transport in Headern und Query-Strings.

Base64URL ist keine Verschlüsselung. Header und Payload sind für jeden lesbar, der die Zeichenkette hat. Die Signatur beweist, dass die ersten beiden Teile von jemandem stammen, der den Signierschlüssel kontrolliert; sie verbirgt den Inhalt nicht.

02

Aufbau eines JWT

Jedes Segment hat eine Rolle in der kompakten JWS-Form:

Header

Enthält typischerweise typ (oft "JWT") und alg (Signaturalgorithmus). Optional kid zur Auswahl des öffentlichen Schlüssels aus einem JWKS oder andere Metadaten.

Payload

JSON-Objekt mit Claims: Subjekt, Gültigkeitsfenster, Zielgruppe und anwendungsspezifische Felder. Verschachtelte Objekte sind erlaubt, wenn der Aussteller sie definiert.

Signatur

Kryptographischer Wert über die Bytes von "header.payload" (die beiden kodierten Segmente und der Punkt), mit dem Algorithmus aus dem Header und entweder gemeinsamem Geheimnis (HMAC) oder asymmetrischem Private Key (RSA, ECDSA, EdDSA).

03

Claims: was im Payload steht

Claims sind Name/Wert-Paare. Ihre Bedeutung hängt vom Kontext ab; RFC 7519 definiert registrierte Namen für konsistente Interpretation.

Registrierte Claims

Beispiele: iss, sub, aud, exp, nbf, iat, jti. exp und nbf sind Unix-Zeitstempel; korrekte Validierung braucht eine vertrauenswürdige Uhr beim Verifizierer.

Öffentliche Claims

Namen können in der IANA-Registry registriert werden. Sie bleiben Konventionen, bis Produzent und Konsument sich einig sind.

Private Claims

Zwischen Aussteller und Konsument vereinbarte Namen (z. B. interne Rollen). Vermeiden Sie Kollisionen mit registrierten Namen, sofern Sie nicht beide Seiten kontrollieren.

04

Algorithmen im Überblick

Der Wert alg im Header bestimmt die Signaturberechnung. Die Wahl des Modells beeinflusst, wer verifizieren kann und wie Geheimnisse geteilt werden.

  • HMAC (HS*): ein gemeinsames Geheimnis signiert und verifiziert. Einfach für einen Dienst, aber jeder Verifizierer braucht das Geheimnis.
  • RSA oder ECDSA/EdDSA: Aussteller signiert mit Private Key; Verifizierer nutzen den Public Key (oft per JWKS). Passt zu Microservices und Clients ohne Signiergeheimnis.
  • Der Algorithmus "none" darf in Produktion nicht akzeptiert werden — sonst unsignierte Tokens bei Fehlkonfiguration. Unbekannte oder deaktivierte Algorithmen explizit ablehnen.
05

Sicherheit: Vertrauen, Privatsphäre, Validierung

Eine gültige Signatur zeigt, dass das Token von jemandem mit Signierschlüssel stammt und Header/Payload unverändert sind. Sie verschlüsselt nichts.

Keine Passwörter, API-Keys oder langlebigen Geheimnisse in den Payload. Für Vertraulichkeit zusätzlich zur Signatur: TLS unterwegs und ggf. JWE — anderes Format und Ablauf.

Server sollten Signatur mit erwartetem Schlüssel/JWKS prüfen, exp (und üblicherweise nbf) prüfen, aud und iss durchsetzen, wenn die Architektur darauf baut, und kurze Lebensdauern plus Refresh nutzen.

06

Typische Einsatzgebiete

JWTs werden oft genutzt für:

  • Identität und Autorisierung (Bearer-Access-Tokens, ID-Tokens in OpenID Connect)
  • Identität oder Delegation zwischen Diensten in verteilten Systemen
  • Sitzungszustand in Clients mit sicherem Speicher und Refresh-Strategien
  • OAuth-2.0-Scopes oder benutzerdefinierte Claims für Gateways und Resource Server
07

Praktische Grenzen

Nützliche Einschränkungen beim JWT-Design:

  • Größe: Tokens gehen oft in HTTP-Headern; große Payloads erhöhen Latenz und stoßen an Proxy-Limits.
  • Widerruf: Ein reines Stateless-JWT ist ohne Zusatzinfrastruktur nicht sofort widerrufbar (Denylists, Introspektion, sehr kurze Lebensdauern).
  • Zeitabweichung: exp- und nbf-Prüfung setzt hinreichend synchronisierte Uhren zwischen Ausstellern und Verifizierern voraus.