Was bedeutet « JWT dekodieren »?
Ein JWT dekodieren (« jwt decode », « decode jwt online ») bedeutet, die Zeichenkette an den beiden Punkten zu teilen und dann jedes Segment in Base64URL zu dekodieren, um das ursprüngliche JSON wiederzufinden. Kein Schlüssel ist nötig: Header und Payload sind nur kodiert, nicht verschlüsselt. Genau dahinter steckt die Suche nach « jwt payload decoder » oder « decode jwt without verify » — den Inhalt des Tokens sehen, ohne zu behaupten, er sei echt.
Unterscheiden Sie die beiden Vorgänge genau. Lesen ein JWT beweist nichts: Jeder kann einen Token mit attraktivem Payload erfinden und mit seinem eigenen Geheimnis signieren. Verifizieren die Signatur beweist, dass der Inhalt von Dritten nicht verändert wurde. Ein Decoder, der « admin: true » ohne Signaturprüfung anzeigt, erzählt eine Geschichte, keine Tatsache.
Die drei Segmente eines JWT
Die Zeichenkette teilt sich genau in drei durch Punkte getrennte Teile: header.payload.signature. Der Header enthält mindestens alg und typ, manchmal kid um anzugeben, welcher Schlüssel verwendet wurde. Das Payload enthält die claims, diese Schlüssel-Wert-Paare, deren Register die IANA führt. Die Signatur umfasst die ersten beiden Segmente verkettet genau so, wie sie geschrieben sind — schon die kleinste Änderung an einem Leerzeichen oder Zeichen lässt den Vergleich scheitern.
Die ganze Schwierigkeit liegt darin, dass diese Segmente Base64URL und nicht Base64 sind: aus dem Plus wird ein Minusstrich, aus dem Schrägstrich wird ein Unterstrich und das Padding = entfällt. Ein klassischer Base64-Decoder scheitert also an einem gültigen JWT. Die Tabelle « Base64URL versus klassisches Base64 » im Referenz-Tab zeigt genau diese Ersetzungen.
Eine Signatur prüfen: HS256, RS256, ES256
Für einen Algorithmus HMAC — HS256, HS384, HS512 — dient dasselbe Geheimnis zum Signieren und Prüfen: Das Tool berechnet HMAC(secret, base64url(header) + "." + base64url(payload)) und vergleicht das Ergebnis mit der mitgelieferten Signatur. Das ist der häufigste und zugleich gefährlichste Fall: Jeder Dienst, der das Geheimnis kennt, kann einen Token ausstellen. Ein Geheimnis von weniger als 32 Byte, das zwischen Umgebungen wiederverwendet wird, genügt, um die ganze Kette zu kompromittieren.
Für die Algorithmen asymmetrischen — RS256, RS384, RS512, ES256, ES384, ES512, PS256 — benötigen Sie zum Prüfen nur den öffentlichen Schlüssel. So können Sie einen von Dritten ausgestellten Token kontrollieren, ohne dessen Signaturgeheimnis je preiszugeben. Fügen Sie den Schlüssel im PEM-Format ein -----BEGIN PUBLIC KEY----- (SPKI); das Rohergebnis eines OpenSSL-Exports ist direkt verwendbar. Bei ES256 liegt die Signatur im rohen r||s-Format vor, genau wie WebCrypto es erwartet.
Schließlich gilt es, die alg confusion : Wenn Ihr Dienst RS256 erwartet, aber einen Token akzeptiert, dessen Header HS256 meldet, signiert ein Angreifer mit dem öffentlichen Schlüssel — der damit zum HMAC-Schlüssel wird — und besteht die Prüfung. Legen Sie den erwarteten Algorithmus serverseitig fest und lesen Sie ihn nie aus dem Token selbst aus.
exp, iat, nbf: die Zeitstempel, die in die Falle tappen
Diese drei Claims sind Unix-Sekunden, ohne Millisekunde und ohne Zeitzonenangabe: iat « 1516239022 » bedeutet 2018-01-17T21:30:22Z. Zwei Fehler tauchen immer wieder auf: Vergleich mit einem Datum in Millisekunden (Wert zehntausendmal zu groß) und Auswertung eines Timestamps lokal statt in UTC. Der Tab « Ablauf » rechnet in beide Richtungen und zeigt ISO 8601, das lokale Datum sowie die verbleibene oder verstrichene Zeit — so erkennen Sie einen « bereits abgelaufenen » Token sofort auf die Sekunde genau.
Die Gültigkeitsdauer zu verlängern erhöht die Sicherheit nicht: ein exp hinausgeschobener Wert ändert nur den angezeigten Wert, nicht die Signatur. Wenn Sie neu ausstellen müssen, signieren Sie den Token erneut mit dem Geheimnis oder dem privaten Schlüssel — genau das ist der Zweck des Tabs « Kodieren ».
Base64URL: warum klassische Decoder scheitern
Base64URL (RFC 4648 §5) verwendet das Alphabet A-Z a-z 0-9 - _ und kennt kein Padding. Ein Payload mit 20 Zeichen ergibt nach Entfernen des = : das ist normal, keine Beschädigung. Die Zeichen - und _ sind für menschliche Augen mehrdeutig — das erklärt die Hälfte der gemeldeten « defekten Tokens ». Unser Decoder akzeptiert beide Alphabete, gemischte Groß-/Kleinschreibung, optionales Padding und ein Bearer.
Sicherheit: was ein JWT nicht leistet
Ein JWT bietet weder Vertraulichkeit noch Sperrbarkeit. Das Payload ist für alle lesbar: niemals E-Mail, interne Rolle oder Personendaten, die Sie nicht im Klarnetz versenden würden. Und ein signierter Token bleibt gültig bis zu exp auch nach dem Abmelden — nötig sind eine Sperrliste, ein jti seitenseitiges Tracking oder kurze Gültigkeitszeiten mit refresh token. Ein guter Instinkt : exp kurz (10 bis 15 Minuten), iat kontrolliert, nbf ausgerichtet an iat, aud und iss bei Empfang geprüft.
Empfohlen für
Backend- und Frontend-Entwickler (OAuth 2.0, OpenID Connect, REST-API), Integratoren und DevOps (Identitätsinfrastruktur, JWKS, Schlüsselrotation), Tester und Pentester (Umschreiben von Claims, alg confusion, Ablauf), Systemadministratoren (Debugging eines unerklärlichen 401), Studierende (Base64URL und WebCrypto verstehen) und alle, die einen JWT-Decoder online schnell, vollständig und vertraulich — ergänzt durch denBase64-Encoder/Decoder, denURL-Encoder/Decoder und den JSON-Formatter.