JWT Decoder

Ein JWT ist ein kompaktes, URL-sicheres Token-Format, das aus drei Base64url-kodierten Teilen besteht: Header, Payload und Signatur, getrennt durch Punkte. JWTs werden häufig für Authentifizierung und Autorisierung in Webanwendungen und APIs verwendet.

Claims sind Schlüssel-Wert-Paare im Payload eines JWT, die Informationen über den Benutzer oder die Sitzung enthalten. Standardisierte Claims sind u. a.: iss (Issuer), sub (Subject), aud (Audience), exp (Ablaufzeit), iat (Ausstellungszeitpunkt) und nbf (Nicht gültig vor).

Der Inhalt eines JWT (Header und Payload) ist lediglich Base64url-kodiert, nicht verschlüsselt. Jeder kann den Inhalt lesen. Die Signatur stellt jedoch sicher, dass der Token nicht manipuliert wurde. Speichern Sie daher keine sensiblen Daten wie Passwörter im JWT. Für verschlüsselte Tokens gibt es JWE (JSON Web Encryption).

Zur Verifizierung der Signatur wird der geheime Schlüssel (bei HMAC) oder der öffentliche Schlüssel (bei RSA/ECDSA) benötigt. Da dieses Tool rein clientseitig arbeitet und der Schlüssel nicht verfügbar ist, kann die Signatur nur angezeigt, aber nicht überprüft werden.

Der exp-Claim (Expiration Time) gibt als Unix-Timestamp an, wann der Token abläuft. Nach diesem Zeitpunkt sollte der Token nicht mehr akzeptiert werden. Unser Tool zeigt automatisch an, ob der Token noch gültig oder bereits abgelaufen ist.

JWS (JSON Web Signature) ist das am häufigsten verwendete JWT-Format, bei dem der Inhalt lediglich signiert, aber nicht verschlüsselt wird – jeder kann den Payload lesen, aber niemand kann ihn unbemerkt verändern. JWE (JSON Web Encryption) hingegen verschlüsselt den gesamten Inhalt, sodass nur autorisierte Empfänger die Daten lesen können. Für die meisten Authentifizierungszwecke reicht JWS aus, während JWE für vertrauliche Daten im Token verwendet wird.

Die wichtigsten registrierten Claims sind: iss (Issuer – wer den Token ausgestellt hat), sub (Subject – für wen der Token bestimmt ist), aud (Audience – welcher Dienst den Token akzeptieren soll), exp (Expiration – Ablaufzeitpunkt), iat (Issued At – Ausstellungszeitpunkt), nbf (Not Before – früheste Gültigkeitszeit) und jti (JWT ID – eindeutige Token-Kennung). Darüber hinaus können beliebige eigene Claims hinzugefügt werden.

Die optimale Gültigkeitsdauer hängt vom Anwendungsfall ab. Für Access Tokens werden typischerweise kurze Laufzeiten von 5 bis 30 Minuten empfohlen, um das Risiko bei kompromittierten Tokens zu minimieren. Refresh Tokens können länger gültig sein (Tage bis Wochen). Generell gilt: Je sensibler die geschützten Ressourcen, desto kürzer sollte die Gültigkeitsdauer gewählt werden.

JWTs sind von Natur aus zustandslos (stateless) und können nicht direkt widerrufen werden, da der Server keinen Status über ausgegebene Tokens speichert. Um Tokens dennoch ungültig zu machen, gibt es verschiedene Strategien: eine serverseitige Blacklist bzw. Revocation-Liste, kurze Gültigkeitsdauern in Kombination mit Refresh Tokens oder das Ändern des Signaturschlüssels, wodurch alle bestehenden Tokens ungültig werden.

Die gängigsten Algorithmen sind HS256 (HMAC mit SHA-256), der einen gemeinsamen geheimen Schlüssel verwendet, sowie RS256 (RSA mit SHA-256), der ein asymmetrisches Schlüsselpaar (privat/öffentlich) nutzt. Für höhere Sicherheit und bessere Performance wird zunehmend ES256 (ECDSA mit P-256-Kurve) empfohlen. Der Algorithmus „none" sollte in Produktionsumgebungen niemals akzeptiert werden, da er keine Signatur erfordert.