JWT Decoder mit Sicherheits-Check und Claim-Glossar

Ein JWT (JSON Web Token) ist ein signiertes Datenpaket aus drei Teilen: Header, Payload, Signatur. Ihn zu lesen ist kein Hack, denn Header und Payload sind base64url-codiert, also nichts Verschlüsseltes. Spannender als der reine Inhalt ist meistens, was mit dem Token nicht stimmt: abgelaufen, alg: none, E-Mail im Payload, schwacher HS256-Secret. Genau das siehst du hier auf einen Blick, bevor du dich durch den Payload klickst.

Was steht eigentlich in deinem JWT?

Ein signierter JWT in JWS-Compact-Form hat drei Segmente, getrennt durch Punkte: Header, Payload, Signatur. Header und Payload sind base64url-codierte JSON-Objekte und ohne Schlüssel lesbar; oben siehst du sie in ihre farbig markierten Bestandteile zerlegt. Verschlüsselte JWTs nach JWE haben fünf Segmente; die akzeptiert dieser Decoder bewusst nicht.

Im Header steht meist nur, welcher Algorithmus signiert hat (alg), welcher Token-Typ vorliegt (typ, fast immer JWT) und optional eine Key-ID (kid), damit der Empfänger den richtigen Public-Key aus seinem JWKS heraussucht. Der Payload trägt die eigentlichen Claims - die sieben Standard-Claims aus RFC 7519 §4.1 plus eine häufige Erweiterung:

• sub - der Betreff (Subject), meist eine User-ID. Stabil über Logins hinweg, für Menschen nicht lesbar.
• iss - der Herausgeber (Issuer), also wer den Token ausgestellt hat. Vertrauen beginnt hier.
• aud - die Zielgruppe (Audience), also für wen der Token gedacht ist. Dein API-Server prüft, ob er hier drinsteht.
• iat / exp / nbf - Zeitstempel als Unix-Sekunden: ausgestellt, läuft ab, frühestens gültig.
• jti - eindeutige Token-ID, nützlich für Revocation-Listen.
• scope - OAuth-Berechtigungen, meist space-separiert. Nicht in RFC 7519 selbst, sondern später in der IANA-JWT-Registry registriert (via RFC 8693).

Diese Claims plus azp (OIDC-Claim) und die typischen Header-Felder (alg, typ, kid) bekommen ein kleines ? - tippst du drauf, erscheint die Ein-Satz-Definition mit Spec-Section. Bei iat, exp und nbf kommt der Unix-Timestamp zusätzlich als UTC-Datum plus relativer Zeitabstand (in 4m 12s oder vor 2h 14m), damit du dafür keinen zweiten Tab brauchst.

Du brauchst kein Secret, um einen JWT zu lesen

Header und Payload eines JWT sind base64url-codiert, nicht verschlüsselt. Zum Lesen reicht der Token selbst - kein Secret, kein Public-Key. Ein Schlüssel kommt erst ins Spiel, wenn du die Signatur prüfen willst, also bestätigen, dass der Token tatsächlich vom genannten Issuer stammt und nicht unterwegs manipuliert wurde.

Viele Decoder fragen trotzdem sofort nach dem Schlüssel, sobald du einen Token einfügst. Das hält den Mythos am Leben, ohne Secret komme man nicht an den Inhalt - und kostet dich den Reflex, einen echten Schlüssel in ein fremdes Eingabefeld einzufügen.

Hier läuft es andersherum: Lesen ist die Standardansicht, die Signaturprüfung sitzt darunter in einer eingeklappten Disclosure und bleibt zu, bis du sie aktiv öffnest. Erst dann erscheint das Schlüsselfeld. Das passt zum häufigsten Workflow: Token aus einem Network-Tab oder Log holen, kurz reingucken, fertig. Die Signatur ist Sache des Servers, der den Token entgegennimmt.

Falls du verifizieren willst, laufen HS256/384/512 (Shared Secret), RS256/384/512 und PS256/384/512 (RSA mit PEM-Public-Key) sowie ES256/384/512 (Elliptic Curve) über die Web-Crypto-API deines Browsers. alg: none bleibt mit Absicht außen vor - der Pitfall-Check markiert das oben, eine Signaturprüfung gibt es nicht, weil es keine wäre.

alg: none ist kein Witz - und dein Decoder warnt dich nicht

alg: none ist ein gültiger JWT-Header-Wert: kein Algorithmus, keine Signatur. Die JWT-Spec lässt das zu, weil Integrität in manchen Setups von außen abgesichert wird (RFC 7519 §6). Eine Library, die alg: none blind akzeptiert, lässt damit jede Manipulation am Payload durchgehen - ein klassischer Auth-Bypass.

Das Angriffsmuster ist trivial:

1. alg im Header von RS256 auf none umschreiben.
2. Im Payload sub auf admin setzen (oder den Claim, den der Server für die Autorisierung liest).
3. Die Signatur weglassen - dritter Punkt, leerer String.
4. Schicken. Wenn der Server akzeptiert, was der Header behauptet, statt explizit zu prüfen, geht das Token durch.

RFC 8725 (JWT BCP) empfiehlt deshalb seit 2020, akzeptierte Algorithmen per Allowlist zu führen und nie aus dem Header zu lesen. Trotzdem taucht der Bug zuverlässig wieder auf. CVE-2026-23993 (HarbourJwt) ist das jüngste Beispiel: Der Verifikationspfad ließ unbekannte alg-Werte durch, none inklusive. Dasselbe Muster („unknown alg"-Bypass) kommt seit Jahren in unterschiedlichen Libraries wieder hoch.

In der Statusanzeige oben erscheint alg: none rot markiert, sobald der Header das ausweist - ob du verifizieren willst oder nicht. Sieben von sieben Decodern in unserer Wedge-Recherche tun das nicht; sie zeigen den dekodierten Header und überlassen dir die Deutung. Wenn du den Token gerade aus einem Log gefischt hast, ist genau das ein Check, der dir sonst entgeht.

Production-Token in einem Web-Tool? Vier Fragen vorher

Jamie Tannas Argument gegen Online-Tooling lautet ungefähr: „Wir bringen Leuten bei, beliebigen Webseiten zu vertrauen, mit denen sie keine Beziehung haben." Bei einem JWT ist das Risiko konkret: Ein Production-Access-Token in ein fremdes Browser-Tool zu kopieren ist potentiell ein Datenleck. Entweder weil das Tool den Token an einen Server schickt (kommt vor), weil das Tool ihn in der URL ablegt (kommt vor), oder weil der Browser ihn via History-Sync auf andere Geräte trägt (kommt vor).

Drei Regeln, an denen sich dieser Decoder gegen genau das festhält:

1. Dein Token verlässt deinen Browser nicht. Kein Upload, kein Logging, kein Server-Roundtrip.
2. Der Token landet nicht in der URL - weder beim Tippen noch beim Teilen. Es gibt bewusst keinen „Share Token"-Button.
3. Sieht der Token nach Production aus (E-Mail im Payload, UUID-förmige Werte, langes exp, bekannter Issuer wie *.auth0.com oder accounts.google.com), erscheint beim Aufklappen der Signaturprüfung ein Hinweis: „Sieht nach Production-Token aus. Sicher?". Wegklickbar mit einem Klick, die Frage stand zumindest da.

Die vier Fragen, die du dir vor einem echten Token stellen kannst:

1. Brauche ich wirklich den Production-Token? Für lokales Debugging tut es meist ein Test-Token aus dem Dev-Issuer.
2. Wer betreibt das Tool? Toolflux ist ein kleines Solo-Projekt aus Deutschland. Kein Backend, keine Daten-Pipeline, alles läuft im Browser deines Geräts. Impressum und Kontakt im Footer.
3. Wird der Token irgendwo abgelegt? Hier nicht - nicht in der URL, nicht im Browser-Storage, nicht in Server-Logs (es gibt keinen Server, der ihn sieht).
4. Wenn doch etwas schiefgeht: Kann ich den Token rotieren? Lautet die Antwort „nein, das ist ein Long-Lived-Refresh-Token mit Admin-Scope", dann gehört der Token nicht in ein Web-Tool.

Häufige Fragen

Was bedeuten sub, aud, iss in einem JWT?

sub (Subject) ist die ID dessen, wem der Token gehört, meist eine User-ID. aud (Audience) sagt, für wen er gedacht ist; dein API-Server prüft, ob er selbst in dieser Liste steht. iss (Issuer) ist der Aussteller, also der Auth-Server. Vertrauen beginnt bei iss. Zu jedem dieser Claims hängt im Decoder ein ?-Chip mit Ein-Satz-Definition und Spec-Section.

Brauche ich den Secret, um einen JWT zu lesen?

Nein. Header und Payload sind nur base64url-codiert, also nichts Verschlüsseltes - zum Lesen reicht der Token selbst. Den Secret oder Public-Key brauchst du erst, wenn du die Signatur prüfen willst.

Was ist alg: none und warum ist das gefährlich?

alg: none ist ein gültiger JWT-Header-Wert: kein Algorithmus, keine Signatur. Server, die blind annehmen, was der Header behauptet, lassen damit beliebige Manipulationen am Payload durchgehen. In der Statusanzeige oben taucht alg: none deshalb rot markiert auf.

Wird mein JWT irgendwo gespeichert?

Nein. Der ganze Decoder läuft im Browser - dein Token wird nicht hochgeladen, nicht in der URL persistiert, nicht in den Browser-Verlauf geschrieben.

Was ist der Unterschied zwischen HS256 und RS256?

HS256 (HMAC-SHA256) ist symmetrisch: Sender und Empfänger teilen denselben geheimen Schlüssel. RS256 (RSA-SHA256) ist asymmetrisch: Nur der Issuer signiert mit seinem Private-Key, alle anderen verifizieren mit dem Public-Key. RS256 ist die richtige Wahl, sobald mehr als ein Service den Token akzeptieren soll.