JWT-Decoder
Dekodiere Header, Payload und Claims eines JWT lokal im Browser. Prüfe Ablaufzeiten, Warnungen und die Signaturdarstellung, ohne das Token zu verifizieren.
Referenz der JWT-Standard-Claims
Die Tabelle fasst die wichtigsten registrierten Claims eines JWT zusammen.
| Claim | Bedeutung | Beispiel |
|---|---|---|
| iss | Aussteller | https://issuer.example |
| sub | Subjekt | user-123 |
| exp | Ablaufzeit | Unix-Zeitstempel |
| aud | Audience | api.example |
| nbf | Nicht gültig vor | Unix-Zeitstempel |
| iat | Ausgestellt am | Unix-Zeitstempel |
Häufige Fragen
Wie ist ein JWT aufgebaut?
Ein JSON Web Token besteht aus drei mit Base64url kodierten Teilen, die durch Punkte verbunden sind: Header.Payload.Signatur. Der Header ist ein kleines JSON-Objekt und nennt den Signaturalgorithmus (alg) und den Tokentyp (typ). Der Payload enthält Claims wie iss, sub, aud, exp, iat und nbf sowie eigene Felder. Die Signatur ist der kryptografische Nachweis, der Header und Payload an einen Schlüssel des Ausstellers bindet. Das Dekodieren ist nur Base64url-Dekodierung und JSON-Parsing. Die Signaturprüfung ist ein separater Schritt.
Ist ein JWT verschlüsselt und kann jede Person den Payload lesen?
Normale JWTs, also die meist verwendeten signierten JWS, sind nicht verschlüsselt. Der Payload ist nur Base64url-kodiert und kann von jeder Person mit dem Token gelesen werden. Die Signatur schützt die Integrität, verbirgt aber nicht den Inhalt. Speichere niemals Passwörter, vollständige Kreditkartennummern oder andere Geheimnisse in einem JWT. Wenn Vertraulichkeit erforderlich ist, verwende geeignete JWE- oder serverseitige Sitzungsmechanismen.
Warum dekodiert dieses Werkzeug das Token, ohne die Signatur zu verifizieren?
Dieses Werkzeug dekodiert das Token nur und erhält keinen vertrauenswürdigen Prüfschlüssel oder eine Konfiguration des Ausstellers. Ein Browser kann ein JWT mit einem bekannten öffentlichen Schlüssel prüfen, aber dieser Decoder ruft keinen Schlüssel ab. Behandle jeden dekodierten Claim als nicht vertrauenswürdig, bis deine Anwendung Signatur, Algorithmus, Aussteller, Audience und Zeit-Claims geprüft hat. Füge kein aktives Bearer-Token in ein Analysewerkzeug ein.
Was bedeuten die Standard-Claims iss, sub, aud, exp, iat und nbf?
RFC 7519 definiert registrierte Claims. iss bezeichnet den Aussteller. sub bezeichnet das Subjekt, meist eine Benutzer-ID. aud nennt die vorgesehene Zielgruppe. exp ist ein Unix-Zeitstempel für den Ablauf. nbf nennt den frühesten Nutzungszeitpunkt. iat bezeichnet die Ausstellung. jti ist eine eindeutige Token-ID, die zum Beispiel für Sperrlisten verwendet wird.
Was ist die Schwachstelle von alg:none?
Die JWT-Spezifikation kennt einen Modus ohne Signatur, in dem alg auf none gesetzt und das Signatursegment leer ist. Ein fehlerhafter Validator kann getäuscht werden, wenn ein Angreifer die Signatur entfernt und alg auf none ändert. Konforme Bibliotheken lehnen alg none ab, sofern die Anwendung es nicht ausdrücklich erlaubt. Produktionscode sollte den erwarteten Algorithmus festlegen, statt dem Header zu vertrauen. Behandle ein solches Token als nicht vertrauenswürdig.
Änderungsverlauf
Aktualisierungen von JWT-Decoder, nach Datum gruppiert.
1 Aktualisierung
JWT-Decoder hinzugefügt
- Dekodiere Header, Payload und Claims eines JWT lokal im Browser. Prüfe Ablaufzeiten, Warnungen und die Signaturdarstellung, ohne das Token zu verifizieren.
Ähnliche Rechner
Weitere geprüfte Rechner im Themenbereich „Technik“.