JSON Web Tokens: Aufbau, was in die Nutzlast gehört und der Unterschied zwischen Dekodieren und Prüfen

Das Lesen eines JWT zeigt gespeicherte Angaben. Deren Verwendung setzt eine eigene Prüfung voraus. Diese Trennung ist wichtig: Plausibel aussehendes JSON lässt sich auch ohne den Signaturschlüssel eines Ausstellers erzeugen.

Die folgende Erklärung behandelt die verbreitete kompakte JWS-Darstellung eines JWT. Drei durch Punkte getrennte Teile enthalten geschützten Header, Nutzlast und Signatur oder Nachrichtenauthentifizierungscode (MAC). Die ersten beiden Teile sind Base64url-kodiertes JSON, nicht verschlüsselt. Ein kompaktes verschlüsseltes JWT verwendet JWE und besitzt fünf Teile. JWT bezeichnet ein Format; nicht jedes JWT ist ein Zugriffstoken.

Was die drei Teile nachweisen

Der Header benennt über alg das kryptografische Verfahren und kann mit kid eine Schlüsselkennung enthalten. Die Nutzlast enthält Claims, also Angaben etwa zu Aussteller, Subjekt, Zielgruppe oder Berechtigungskontext. Der dritte Teil schützt den kodierten Header und die Nutzlast vor unbemerkter Veränderung und bestätigt die Erstellung durch eine Stelle mit dem zugehörigen Signatur- oder MAC-Schlüssel.

Bei einem asymmetrischen Verfahren signiert der private Schlüssel; der passende öffentliche Schlüssel dient zur Prüfung. Bei HS256 erzeugt und prüft ein gemeinsames Geheimnis den MAC. Jede Stelle mit diesem Geheimnis kann ebenfalls gültige MACs erzeugen; die Prüfung identifiziert daher nicht eindeutig eine einzelne dieser Stellen. Ein gültiges Ergebnis mit einem beliebigen Schlüssel genügt nicht: Die Anwendung muss diesem Schlüssel für den erwarteten Aussteller und Zweck vertrauen.

Dekodierung, Validierung und Berechtigung

1. Dekodierung: Die erwartete Darstellung einlesen und Felder zunächst als nicht vertrauenswürdige Eingaben behandeln.
2. Kryptografische Prüfung: Nur konfigurierte Verfahren und geeignete vertrauenswürdige Schlüssel zulassen; Signatur oder MAC tatsächlich prüfen.
3. Kontextprüfung: Aussteller, Zielgruppe, Tokentyp, Pflichtangaben und Zeitregeln des maßgeblichen Profils durchsetzen.
4. Berechtigungsprüfung: Entscheiden, ob das geprüfte Subjekt mit seinen Rechten diese Aktion auf dieser Ressource ausführen darf.

Ein Decoder kann auch ein erfundenes Token anzeigen. Umgekehrt kann ein korrekt signiertes Token für eine andere Zielgruppe bestimmt, abgelaufen oder für das angefragte Konto unzureichend berechtigt sein. Ein Bibliotheksaufruf hilft nur, wenn Konfiguration und zusätzliche Anwendungsprüfungen die vorgesehenen Regeln umsetzen.

Die Anwendung legt die erlaubten Algorithmen fest; alg muss dazu und zum zulässigen Schlüsseltyp passen. Ein unsigniertes Token mit alg: none ist dort unzulässig, wo eine Signatur verlangt wird. Die Verwechslung von RS256 und HS256 betrifft anfällige oder falsch konfigurierte Prüfer und ist kein unvermeidliches Verhalten jeder Bibliothek. Ein öffentlicher RSA-Schlüssel darf niemals als HMAC-Geheimnis verwendet werden.

kid ist ein zunächst nicht vertrauenswürdiger Auswahlhinweis. Zulässig ist die Auswahl innerhalb eines für den Aussteller vertrauenswürdigen Schlüsselsatzes, etwa eines sicher abgerufenen JWKS. Beliebige Schlüssel, URLs oder Dateipfade aus dem Token dürfen daraus keine Berechtigung erhalten. Ein ID-Token ist nicht allein deshalb als API-Zugriffstoken geeignet, weil beide JWT verwenden.

Angaben passend zur tatsächlichen Aufgabe

Passwörter, private Schlüssel und unnötige personenbezogene Angaben gehören nicht in eine lesbare Nutzlast. Auch eine kurze Kennung kann sensibel sein. Reale Tokens benötigen deshalb Schutz bei Speicherung, Übertragung, Diagnose und Support; Demonstrationsmaterial sollte synthetische Daten enthalten.

Rollen, Berechtigungsbereiche oder Mandantenkennungen sind nicht grundsätzlich verboten. RFC 9068 sieht Rollen und verwandte Berechtigungsangaben ausdrücklich vor. Entscheidend sind Bedarf des empfangenden Dienstes, Offenlegungsrisiko und erforderliche Reaktionszeit auf Änderungen. Eine Rolle in einem ausgestellten Token kann veralten. Serverabfragen, kurze Laufzeiten oder andere Kontrollen können nötig sein; eine Serverabfrage findet nicht automatisch in jeder JWT-Architektur statt.

sub bezeichnet das Subjekt, iss den Aussteller und aud den vorgesehenen Empfänger beziehungsweise mehrere Empfänger. RFC 7519 verlangt nicht sämtliche registrierten Claims in jedem JWT. Ein konkretes Protokollprofil kann Pflichtfelder festlegen; das OAuth-Zugriffstokenprofil aus RFC 9068 enthält zusätzliche Anforderungen. Das bloße Vorhandensein genügt nicht: Aussteller und Zielgruppe müssen mit den erwarteten Werten übereinstimmen.

Ablaufzeit und serverseitige Regeln

exp und nbf verwenden NumericDate-Werte in Sekunden seit der Unix-Epoche, keine JavaScript-Millisekunden. Ohne Uhrtoleranz setzt die Annahme now < exp und bei vorhandenem nbf now >= nbf voraus. Genau zum Ablaufzeitpunkt ist das Token abgelaufen. Der Server muss außerdem die Pflichtfelder seines Profils verlangen; ein fehlendes exp darf eine vorgeschriebene Ablaufprüfung nicht stillschweigend umgehen.

Ohne exp gilt ein Token nicht allgemein unbegrenzt. Serverregeln, Widerruf, Kontozustand und Schlüsselvertrauen können die Annahme unabhängig verhindern. Das Löschen einer Browserkopie widerruft andere Kopien nicht. Mögliche Architekturen kombinieren kurzlebige Zugriffstokens mit widerrufbaren Auffrischungstokens, Sperrlisten oder Introspektion. Eine jti-Kennung allein setzt weder Widerruf noch Schutz vor Wiederverwendung um.