JWT

JWT (JSON Web Token, ausgesprochen „jot“) ist ein Token-Format, das in RFC 7519 für die Übertragung signierter Claims zwischen Parteien definiert ist. Ein JWT besteht aus drei base64url-kodierten, durch Punkte getrennten Segmenten: header.payload.signature.

Der Header deklariert den Signaturalgorithmus (HS256, RS256, ES256 usw.). Die Nutzlast ist ein JSON-Objekt aus Claims – sub (Subjekt), iss (Aussteller), exp (Ablauf), iat (ausgestellt am) sowie beliebige anwendungsspezifische Felder. Die Signatur wird über base64url(header) + "." + base64url(payload) mit dem im Header deklarierten Algorithmus und Schlüssel berechnet.

JWTs werden für zustandslose Authentifizierung verwendet (der Server muss keine Sessions speichern; er prüft bei jeder Anfrage die Signatur), für die Autorisierung zwischen Diensten (OAuth-2.0-Bearer-Token, OpenID-Connect-ID-Token) und für kurzlebige URLs, die Zugriffs-Claims kodieren.

Häufige Fallstricke: alg: none zu vertrauen, symmetrisch verschlüsselte Token zu akzeptieren, wo asymmetrische erwartet wurden, exp nicht zu validieren. Der JWT-Decoder prüft den Inhalt eines Tokens – er verifiziert die Signatur nicht, da die Prüfung den Schlüssel des Ausstellers erfordert.

Durchgerechnetes Beispiel

Dekodieren Sie das JWT eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NSIsIm5hbWUiOiJBbGljZSIsImlhdCI6MTcxNjQwMDAwMCwiZXhwIjoxNzE2NDg2NDAwfQ.signature. Header: {"alg":"HS256","typ":"JWT"}. Nutzlast: {"sub":"12345","name":"Alice","iat":1716400000,"exp":1716486400}. Das Token wurde zur Unix-Zeit 1716400000 ausgestellt (ein Zeitpunkt im Mai 2024) und läuft 86.400 Sekunden später ab – genau 24 Stunden. Ein Prüfer, der dieses Token erhält, muss: (1) den HMAC-SHA256 von header.payload mit dem gemeinsamen Geheimnis neu berechnen und prüfen, ob er mit der Signatur übereinstimmt; (2) exp gegen die aktuelle Zeit prüfen und bei Ablauf ablehnen; (3) optional prüfen, ob iss (Aussteller) und aud (Zielgruppe) den erwarteten Werten entsprechen. Jeder – einschließlich des Browsers des Nutzers, jedes zwischengeschalteten Proxys oder eines Angreifers, der das Token stiehlt – kann die Nutzlast base64-dekodieren und Alices Namen und Nutzer-ID sehen. Das Token ist signiert, nicht verschlüsselt.

Wann und warum es zählt

JWT zählt immer dann, wenn zustandslose Authentifizierung die Designentscheidung ist – typisch für SPAs, die mit REST-APIs kommunizieren, mobile Apps mit Backend-Diensten, OAuth-2.0-/OpenID-Connect-Föderationen und die Autorisierung zwischen Microservices. Die zu vermeidenden Fehler: (1) personenbezogene oder sensible Daten in die Nutzlast zu legen (sie ist für jeden lesbar, der das Token hat); (2) lange Ablaufzeiten ohne Widerrufsstrategie zu verwenden (Token mit 24 h+ sind gefährlich, wenn sie gestohlen werden); (3) alg: none zu akzeptieren oder das Token den Algorithmus wählen zu lassen; (4) JWTs in localStorage zu speichern, wo XSS sie stehlen kann – bevorzugen Sie httpOnly-Cookies mit SameSite=Lax; (5) aud nicht zu validieren und Token zu akzeptieren, die für Schwesterdienste ausgestellt wurden. Das bewährte Muster: 5–15 Minuten gültige Access-Token + widerrufbare, langlebige Refresh-Token + undurchsichtige serverseitige Session für wirklich sensible Vorgänge. Quelle: RFC 8725 – JSON Web Token Best Current Practices.

Warum JWTs standardmäßig nicht verschlüsselt sind: Ein gewöhnliches JWT ist signiert, aber nicht vertraulich – jeder mit dem Token kann die Nutzlast base64-dekodieren und jeden Claim lesen, einschließlich der E-Mail-Adresse des Nutzers, seiner Rollen und aller anwendungsspezifischen Daten, die der Aussteller einzubetten wählte. Das erwischt Entwickler immer wieder: personenbezogene Daten oder interne Nutzer-IDs in ein JWT zu legen und anzunehmen, das Token sei eine Blackbox, ist ein Datenleck, das nur darauf wartet zu passieren. Für Vertraulichkeit verschlüsseln Sie die Nutzlast mit JWE (JSON Web Encryption, RFC 7516), das ein Token mit fünf Segmenten und echter Verschlüsselung neben der Signatur erzeugt. Die meisten produktiven Systeme halten entweder personenbezogene Daten aus der Nutzlast heraus oder verwenden undurchsichtige Session-Token mit serverseitigen Statusabfragen.

Refresh-Token, Ablauf und das Widerrufsproblem: Die zustandslose Prüfung ist das Aushängeschild von JWT und zugleich seine größte betriebliche Schwachstelle – einmal ausgestellt, kann ein JWT nicht widerrufen werden, bis es abläuft. Die Standardgegenmaßnahme sind kurzlebige Access-Token (5–15 Minuten), gepaart mit langlebigen Refresh-Token (Tage bis Monate), die über eine serverseitige Sperrliste widerrufbar sind; der Client tauscht das Refresh-Token regelmäßig gegen ein frisches Access-Token. Langlebige JWTs (24 Stunden und mehr) sind für alles Sensible ein Anti-Muster – ein gestohlenes Token ist bis zum Ablauf ein Freifahrtschein. Der JWT-Decoder von Convertitive hebt den exp-Claim hervor, sodass Sie schnell sehen, ob ein Token zu lange gültig ist. Quelle: RFC 7519 – JSON Web Token.