JWT Decoder und Anspruchsprüfer

Dekodieren Sie ein kompaktes JSON Web Token mit drei Teilen, um Header und Ansprüche anzusehen und Zeitangaben mit der aktuellen Uhr zu vergleichen. Das Dekodieren prüft keine Signatur und begründet kein Vertrauen.

Token Eingabe

Kompaktes JWT

Das Token bleibt nur im Seitenspeicher und wird nicht gespeichert. Beim Laden entfernt das Werkzeug ein Token, das eine ältere Version dieser Seite im Browserspeicher hinterlassen hat. Dieses Werkzeug sendet kein Token an eine API.

Verwenden Sie zum Lernen ein Testtoken ohne Zugriff auf ein echtes Konto. Teilen Sie kein Token, das Kontozugriff gewähren könnte.

Dekodierter Token Aufbau

Fügen Sie ein kompaktes JWT mit drei Teilen ein, um Header und Nutzdaten anzusehen.

Quellen

So funktioniert die JWT Prüfung

Ein kompaktes signiertes JWT hat drei durch Punkte getrennte Base64url Teile: einen JSON Header, einen JSON Nutzdatenblock mit Ansprüchen und ein Signatursegment. Dieses Werkzeug dekodiert Header und Nutzdaten als UTF 8 JSON Objekte. Es prüft weder Signatur noch Aussteller, Empfänger, Berechtigungen oder Zugriff.

Geben Sie ein kompaktes Token mit drei Teilen ein. Header und Nutzdaten erscheinen als formatiertes JSON. Die Tabelle zeigt häufige Ansprüche wie iss, sub, aud, exp, iat und nbf. Dieses Werkzeug unterstützt das verschlüsselte Format mit fünf Teilen nicht. Sein geschützter Header kann als JSON lesbar sein, aber die verschlüsselten Ansprüche in den Nutzdaten sind ohne Entschlüsselung nicht einsehbar.

NumericDate Werte in exp, iat und nbf werden als Sekunden seit der UTC Epoche verstanden, auch mit Nachkommastellen. Ablauf und Beginn der Gültigkeit werden mit der angezeigten Uhr verglichen. Fehlende und fehlerhafte Datumswerte werden getrennt angezeigt. Diese Vergleiche bestätigen weder das Token noch seine Ansprüche.

Ein als vorhanden markiertes Signatursegment bedeutet nur, dass der dritte Teil Text enthält. Das Werkzeug prüft weder den kryptografischen Wert noch Algorithmus, Schlüssel oder Aussteller. Behandeln Sie dekodierte Ansprüche als nicht vertrauenswürdig, bis der ausstellende Dienst das Token geprüft hat.

Schritt für Schritt

Fügen Sie ein kompaktes JWT mit drei Teilen in das Tokenfeld ein.
Prüfen Sie den dekodierten Header, die Nutzdaten, das Signatursegment und die angezeigten Ansprüche.
Vergleichen Sie exp und nbf mit der angezeigten Uhr und lassen Sie das Token vor einer Verwendung mit dem erwarteten Schlüssel und den passenden Regeln prüfen.

Rechenbeispiel

Fügen Sie dieses Beispiel Token ein: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwczovL2lzc3Vlci5leGFtcGxlIiwic3ViIjoidXNlci0xMjMiLCJhdWQiOiJhcGkuZXhhbXBsZSIsImV4cCI6MTg5MzQ1NjAwMCwiaWF0IjoxODkzNDUyNDAwLCJuYmYiOjE4OTM0NTI0MDB9.c2ln. Der Header enthält alg HS256 und typ JWT. Die Ansprüche nennen Aussteller, Betreff, Empfänger, Ablauf, Ausgabezeit und Gültigkeitsbeginn.

Das Beispiel enthält Text im dritten Segment. Daher meldet die Anzeige eine vorhandene Signaturzeichenfolge, prüft sie aber nicht. exp entspricht dem 1. Januar 2030 um 00:00 UTC; iat und nbf entsprechen dem 31. Dezember 2029 um 23:00 UTC. Der Vergleich hängt von der aktuellen Uhrzeit ab.

Wann dieser Prüfer hilft

Nutzen Sie ihn, um während Entwicklung oder Fehlersuche den JSON Header und die Ansprüche eines kompakten Tokens mit drei Teilen anzusehen.

Lassen Sie Signaturen und Berechtigungen von einem getrennten vertrauenswürdigen Dienst prüfen. Behandeln Sie dekodierte Inhalte bis dahin als nicht vertrauenswürdig.

Häufige Fehlinterpretationen

Lesbares JSON, ein vorhandenes Signatursegment oder ein noch nicht abgelaufener exp Anspruch beweisen keine Echtheit. Dekodierung und Zeitvergleich sind keine kryptografische Prüfung.

Nehmen Sie nicht an, dass iss, aud, sub oder eigene Berechtigungsangaben wahr sind, nur weil sie in den Nutzdaten stehen. Ein Dienst muss die Signatur prüfen und eigene Regeln für Ansprüche und Zugriff anwenden.

JWT Aufbau und Zeitansprüche

Kompaktes JWT = Base64url(UTF8(JSON Header)) . Base64url(UTF8(JSON Nutzdaten)) . Signatursegment

Ablauf erreicht = aktuelle UTC Zeit in Sekunden ≥ exp

Gültigkeitsbeginn erreicht = aktuelle UTC Zeit in Sekunden ≥ nbf

NumericDate = Sekunden seit 01.01.1970, 00:00:00 UTC

Dieses Werkzeug untersucht die kompakte signierte Form mit drei Teilen. Es dekodiert ungepolstertes Base64url und UTF 8 streng und verlangt JSON Objekte für Header und Nutzdaten. Ein angezeigter Ablauf oder Gültigkeitsbeginn ist nur ein Uhrenvergleich, keine Signaturprüfung oder Authentifizierungsentscheidung.

Umfang und Grenzen

Diese Seite untersucht ein kompaktes JWT mit drei Teilen und dekodiert Header und Nutzdaten. Sie prüft keine Signaturen, Algorithmen oder Schlüssel, bestätigt weder Aussteller noch Empfänger, bewertet keine Berechtigungen und entscheidet nicht, ob eine Anwendung das Token annehmen soll. Sie entschlüsselt keine JWE Tokens mit fünf Teilen, ruft keine Schlüssel ab und kontaktiert weder Aussteller noch Token Dienst. JSON Zahlen außerhalb der unterstützten Genauigkeit werden abgelehnt; angezeigte Daten haben Millisekundengenauigkeit. Zeitansprüche werden mit der Browseruhr verglichen, die von der Uhr eines Dienstes abweichen kann. Das Werkzeug speichert das Token nicht, aber Personen mit Zugriff auf die offene Seite können es sehen.

Begriffe

JWT: JSON Web Token, eine Struktur für Ansprüche, die signiert, gegen Änderungen geschützt oder verschlüsselt sein kann.
Anspruch: Benannter Wert in den Token Nutzdaten, etwa Aussteller, Betreff, Empfänger oder Zeitangabe.
NumericDate: Sekunden seit dem 01.01.1970 um 00:00:00 UTC. Bruchteile einer Sekunde sind zulässig.

FAQ

Ist ein dekodiertes Token gültig?

Nein. Das Dekodieren zeigt nur die lesbare Struktur. Es beweist weder, dass ein vertrauenswürdiger Dienst das Token ausgestellt hat, noch dass sein Inhalt verlässlich ist.

Prüft das Werkzeug die Signatur?

Nein. Es meldet nur, ob das dritte Segment Text enthält. Eine Prüfung muss den erwarteten Algorithmus und einen vertrauenswürdigen Schlüssel des Ausstellers verwenden.

Warum werden Tokens mit fünf Teilen nicht unterstützt?

Ein kompaktes JWE mit fünf Teilen kann einen geschützten Header enthalten, der als JSON lesbar ist. Die verschlüsselten Ansprüche in den Nutzdaten sind ohne Entschlüsselung nicht einsehbar. Dieses Werkzeug unterstützt nur kompakte JWTs mit drei Teilen.

Was bedeuten exp, iat und nbf hier?

Das sind NumericDate Ansprüche in Sekunden seit der UTC Epoche. Das Werkzeug vergleicht exp und nbf mit der aktuellen Uhr und zeigt iat als Datum an. Fehlende oder fehlerhafte Werte werden getrennt markiert. Diese Vergleiche bestätigen das Token nicht.

Was beweist ein vorhandenes Signatursegment?

Nur, dass der dritte Teil nicht leer ist. Das Werkzeug prüft weder Signaturbytes noch Algorithmus, Schlüssel, Aussteller, Empfänger oder Berechtigungen.