DEVELOP.03 JWT DECODER

JWT-Decoder

Token, Header, Payload und Zeit-Claims bleiben auf der ersten Ansicht sichtbar. JSON und Claims teilen sich Tabs; die HMAC-Prüfung erscheint nur bei passenden Algorithmen.

TOKEN

JWT einfügen

Warte auf ein Token

HEADER

Header

PAYLOAD

Payload

SIGN

Signatur und Zeitstatus

§ 01

So untersuchst du ein JWT sicher

Token einfügen

Das Tool teilt die drei Base64URL-Segmente und zeigt Header und Payload als Klartext-JSON an.

Zeit-Claims prüfen

Öffne die Claims-Ansicht, um Ortszeiten und den relativen Status von exp, nbf und iat zu sehen, einschließlich abgelaufener oder noch nicht aktiver Tokens.

Bei Bedarf prüfen

Bei HS-Algorithmen kannst du das gemeinsame Secret eingeben und lokal prüfen. Erfolgreiches Dekodieren macht eine Signatur nicht vertrauenswürdig.

§ 02

Lesbar bedeutet nicht vertrauenswürdig

Ein JWT besteht aus drei durch Punkte getrennten Segmenten. Der Header nennt Algorithmus und Typ, das Payload enthält Claims und die Signature prüft, ob die ersten beiden Segmente unverändert sind. Die ersten beiden sind Base64URL-kodiert und daher ohne Schlüssel lesbar.

Ein häufiger Fehler beim Debuggen ist, ein plausibles Payload zu sehen und das Token deshalb für gültig zu halten. Eine echte Autorisierung muss Signatur, Aussteller, Zielgruppe, Zeitfenster und eine Liste erlaubter Algorithmen serverseitig prüfen.

§ 03

Häufige registrierte Claims

Claim

Bedeutung

Zu prüfen

iss

Aussteller

Passt zum erwarteten Identitätsdienst

sub

Betreff / Benutzer

Bezeichnet das vorgesehene Subjekt

aud

Zielgruppe

Enthält den aktuellen Dienst

exp

Ablaufzeit

Aktuelle Zeit liegt davor

nbf

Gültig ab

Aktuelle Zeit liegt nicht davor

iat

Ausgestellt am

Liegt in einem plausiblen Zeitfenster

jti

Eindeutige Token-ID

Kann Widerruf und Replay-Schutz unterstützen

§ 04

Häufige Fragen

Q1Was ist der Unterschied zwischen Dekodieren und Verifizieren eines JWT?

Dekodieren stellt nur Base64URL-Text als JSON wieder her und benötigt keinen Schlüssel. Die Verifikation nutzt das richtige Secret oder den öffentlichen Schlüssel, um unveränderte Inhalte und einen vertrauenswürdigen Aussteller zu bestätigen.

Q2Ist das Payload verschlüsselt?

Bei einem normalen JWT sind Header und Payload kodiert, nicht verschlüsselt. Lege dort keine Passwörter, privaten Schlüssel oder sonstigen Geheimnisse ab, die Clients nicht sehen sollen.

Q3Was bedeuten exp, nbf und iat?

exp ist die Ablaufzeit, nbf der früheste gültige Zeitpunkt und iat die Ausstellungszeit. Üblicherweise sind es Unix-Zeitstempel in Sekunden.

Q4Warum werden hier nur HS-Algorithmen geprüft?

HS256, HS384 und HS512 verwenden ein klar eingegebenes gemeinsames Secret. RS und ES benötigen Formate öffentlicher Schlüssel und Kurvenparameter; deshalb bleibt die Seite dort beim Dekodieren.

Q5Werden Tokens und Secrets gespeichert?

Nein. Dekodierung und HMAC-Prüfung erfolgen ausschließlich im Speicher der aktuellen Seite, ohne Upload und ohne Browser-Speicher.