Tool-Hinweise
Über JWT-Decoder und Parser
Ein JWT Parser decodiert Header und Payload eines JSON Web Token, damit alg, typ, Signaturstatus und Claims wie iss, sub, aud, iat, nbf und exp geprüft werden können.
Das Werkzeug analysiert Tokens lokal im Browser und kann bearbeitete Header/Payload-Daten mit einem lokalen HMAC-Secret neu signieren. Das Token wird nicht an wetool.site gesendet.
So nutzen Sie den JWT Parser
- Fügen Sie ein vollständiges JWT im Format header.payload.signature ein.
- Klicken Sie Decode, um Header, Payload und die Claim-Zusammenfassung zu prüfen.
- Prüfen Sie exp, nbf und iat; meist sind das Unix-Sekunden.
- Für HMAC-Testtokens geben Sie ein Secret ein, um bearbeitete Header/Payload-Daten lokal neu zu signieren.
Typische Einsatzfälle
- Eine Auth-Session debuggen und prüfen, ob ein Token abgelaufen oder noch nicht gültig ist.
- Bestätigen, dass alg, typ, iss, aud und sub zum API-Gateway oder Backend-Vertrag passen.
- Payload-JSON lesbar formatieren, um scope, role, tenant_id oder andere App-Felder zu finden.
- Einen Claim in einem Entwicklungstoken ändern und lokal mit bekanntem HMAC-Secret neu signieren.
JWT-Struktur, Claims und Signaturgrenzen
Ein JWT hat meist drei Base64URL-Teile: Header, Payload und Signature. Header/Payload zu decodieren erfordert kein Secret, aber Vertrauen in das Token erfordert Signaturprüfung mit dem richtigen Schlüssel.
- Header: enthält meist alg und typ für Signaturalgorithmus und Tokentyp.
- Payload: enthält Claims wie iss, sub, aud, iat, nbf, exp und app-spezifische Felder.
- Signature: schützt Header/Payload vor Manipulation; Decoding beweist keine gültige Signatur.
- Zeit-Claims: iat, nbf und exp sind meist Unix-Sekunden, nicht Millisekunden.
Häufige Fragen zu JWT Parser
- Ist JWT decoding dasselbe wie Verifikation?
- Nein. Decoding liest nur Header und Payload. Verifikation prüft die Signature mit richtigem Secret oder Public Key.
- Warum kann ich den Payload ohne Passwort lesen?
- JWT Header und Payload sind Base64URL-codiert, nicht verschlüsselt. Speichern Sie keine Secrets in normalem JWT Payload.
- Was sind exp, iat und nbf?
- exp ist die Ablaufzeit, iat der Ausstellungszeitpunkt und nbf der Zeitpunkt, ab dem das Token gilt. Üblich sind Unix-Sekunden.
- Funktioniert ein Token nach Bearbeitung des Payload?
- Normalerweise nicht ohne neue Signatur. Dieses Werkzeug kann HMAC-Testtokens lokal neu signieren, wenn ein Secret eingegeben wird.
- Wird mein JWT hochgeladen?
- Nein. Decoding, Bearbeitung und HMAC-Neusignierung laufen lokal im Browser und werden nicht an wetool.site gesendet.
JWT vs Session Cookies
Eine Session speichert Zustand meist serverseitig und gibt dem Browser eine Sitzungs-ID. Ein JWT trägt Claims im Token, was zwischen Services hilft, aber Ablaufzeiten, Schlüssel und Payload-Inhalte wichtiger macht.
JWT-Signaturprüfung und alg-Checkliste
Ein dekodierbares JWT ist nicht automatisch vertrauenswürdig. Echte Verification muss algorithm, key source, issuer, audience und signature policy festlegen.
- Den verification algorithm nicht allein aus dem token alg header wählen; Server sollten eine konfigurierte allowlist nutzen.
- alg=none, HS256/RS256 confusion oder kid values mit externen Zielen als high-risk configuration behandeln.
- Dieses Werkzeug ist gut für Untersuchungen und HMAC-Test-Tokens, aber Prüfung in der Produktionsumgebung gehört ins Backend oder Authentifizierungs-Gateway.
exp, nbf und iat Zeit-Debugging
Die Zeit-Claims eines JWT sind meist Unix-Sekunden. Wenn die Ablaufzeit falsch wirkt, prüfen Sie zuerst die Verwechslung von Sekunden und Millisekunden, den Uhrenversatz und die angezeigte Zeitzone.
- Liegt exp vor den aktuellen Unix-Sekunden, ist das Token abgelaufen; liegt nbf nach dem jetzigen Zeitpunkt, ist es noch nicht gültig.
- 13-stellige Millisekunden als Sekunden zu lesen ergibt ein weit entferntes Datum; 10-stellige Sekunden als Millisekunden landen nahe 1970.
- Server sollten NTP sync halten und small clock skew erlauben, aber lange grace periods sollten keine configuration mistakes verstecken.