Dekodieren Sie JWTs lokal mit dem JWT-Dekoder. Token einfügen, Claims lesen – nichts wird hochgeladen.
Warum Tokens in Fehlerprotokollen landen
Der Stacktrace sagt 401, die Request-Header wurden zum Debuggen protokolliert, und da ist es: ein vollständiges JWT in der Logausgabe, oft aus einem Testlauf oder einem fehlkonfigurierten Client.
Dieses Token ist kein Rauschen. Es enthält Claims – Subject, Issuer, Audience, Ablauf – die genau erklären, warum die Authentifizierung fehlschlug, sofern Sie sie lesen können.
Das Problem ist das Wie. Ein Token in einen beliebigen Online-Dekoder einzufügen sendet es an den Server dieser Seite, wo es protokolliert, gespeichert oder wiederverwendet werden kann. Ein JWT ist in vielen Systemen eine Inhaber-Anmeldedaten; behandeln Sie es als sensibel.
Was ein JWT enthält
Ein JWT besteht aus drei durch Punkte getrennten Segmenten: Header, Payload und Signatur. Header und Payload sind Base64URL-kodiertes JSON, von jedem lesbar – Kodierung ist keine Verschlüsselung.
Die Signatur ist der einzige Teil, der den Signaturschlüssel erfordert, um erzeugt zu werden; zum Debuggen von Claims brauchen Sie sie nicht. Dekodieren heißt nur, die ersten beiden Segmente zu lesen.
Häufig geprüfte Claims: exp (Ablauf, Unix-Sekunden), iat (Ausgestellt am), nbf (Nicht vor), iss (Issuer), aud (Audience), sub (Subject) sowie benutzerdefinierte Claims Ihres Dienstes.
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5cEin Token aus einer Logzeile debuggen
- Kopieren Sie das vollständige JWT aus dem Log – beide Punkte eingeschlossen, sonst schlägt das Dekodieren fehl.
- Öffnen Sie den JWT-Dekoder in Ihrem Browser.
- Fügen Sie das Token ein. Der Dekoder zeigt Header- und Payload-Claims, ohne etwas an einen Server zu senden.
- Prüfen Sie exp gegen die aktuelle Unix-Zeit, dann iat und nbf: Ein Token, das fünf Minuten nach der Ausstellung als abgelaufen gilt, ist meist ein Uhren- oder Zeitzonenproblem.
- Vergleichen Sie iss und aud mit den Erwartungen Ihrer API – Abweichungen verursachen genau die 401er, die Tokens in Logs hinterlassen.
- Redigieren Sie das Token, bevor Sie Logs mit anderen teilen – auch intern.
Dekodieren ist nicht Verifizieren
Dekodieren liest Claims; Verifizieren beweist, dass das Token vom erwarteten Schlüssel signiert und nicht verändert wurde.
Fürs Debuggen reicht Dekodieren meist, um den Fehler zu identifizieren. Für alles, was Zugriff gewährt, verifizieren Sie immer die Signatur mit dem öffentlichen Schlüssel des Issuers und prüfen exp, nbf, iss und aud.
Wenn eine Dekoder-Seite behauptet, Signaturen zu prüfen, seien Sie misstrauisch: Verifikation erfordert den geheimen Schlüssel, den ein entfernter Dienst niemals von Ihnen verlangen sollte.
Warnung: Fügen Sie ein Token niemals in eine Seite ein, die den Signaturschlüssel verlangt, und niemals Tokens aus Produktionssystemen in ungeprüfte Online-Werkzeuge. Lokales, clientseitiges Dekodieren ist der sichere Standard.
Was die Claims meist verraten
| Symptom | Zu prüfender Claim | Typische Lösung |
|---|---|---|
| 401 direkt nach Ausstellung | iat / nbf / Server-Uhr | Uhr-Drift beheben, Toleranz erlauben, Serverzeit synchronisieren |
| Token funktionierte, dann nicht mehr | exp | Erneuern oder neu anmelden; Ablaufzeit prüfen |
| Von API abgelehnt, dekodiert aber fehlerfrei | iss / aud | Issuer- und Audience-Konfiguration angleichen |
| Ungültige Signatur | Header alg + Schlüssel | Signaturschlüssel und Algorithmus auf beiden Seiten prüfen |
Tokens gar nicht erst ins Log lassen
- Loggen Sie in Produktion niemals Authorization-Header oder Cookie-Werte
- Maskieren oder kürzen Sie Tokens in Debug-Ausgaben
- Nutzen Sie strukturierte Logs, damit sensible Felder zentral gefiltert werden können
- Ergänzen Sie einen CI-Check, der bei JWT-ähnlichen Mustern in Testausgaben fehlschlägt
- Rotieren Sie Tokens, die protokolliert oder im Klartext geteilt wurden
FAQ
Q.Ist es sicher, ein JWT online zu dekodieren?
A.Nur wenn das Werkzeug clientseitig ist und keine Netzwerkanfrage mit Ihrem Token macht. Auf dieser Seite geschieht das Dekodieren lokal im Browser. Jedes Werkzeug, das das Token hochlädt, sollten Sie für Produktions-Anmeldedaten meiden.
Q.Warum sagt mein Token abgelaufen, obwohl ich es gerade erstellt habe?
A.Prüfen Sie Server-Uhr und Zeitzone. exp ist in Unix-Sekunden – ist die Server-Uhr voraus oder stammt das Token aus einer anderen Zeitquelle, kann ein frisches Token sofort abgelaufen wirken. Toleranz gegen Uhr-Drift behebt das meist.
Q.Brauche ich das Geheimnis, um ein JWT zu dekodieren?
A.Nein. Header und Payload sind schlichtes Base64URL-kodiertes JSON. Das Geheimnis brauchen Sie nur zur Signaturprüfung, und Sie sollten es niemals mit einem entfernten Werkzeug teilen.
Q.Warum steht im Header alg: none?
A.Das bedeutet, das Token ist unsigniert – jeder kann beliebige Claims fälschen. Server müssen none strikt ablehnen. Sehen Sie es in Logs, prüfen Sie sofort die Konfiguration Ihrer Token-Bibliothek.
Q.Kann jemand ein im Log gefundenes Token verwenden?
A.Bis zum Ablauf ja, sofern es als Inhaber-Anmeldedaten akzeptiert wird und die Audience passt. Behandeln Sie protokollierte Tokens als kompromittiert, redigieren Sie Logs und rotieren Sie das Token.
Referenzen
- RFC 7519 – JSON Web Token (JWT): https://www.rfc-editor.org/rfc/rfc7519
- RFC 7515 – JSON Web Signature (JWS): https://www.rfc-editor.org/rfc/rfc7515
- RFC 4648 – Base64- und Base64URL-Kodierung: https://www.rfc-editor.org/rfc/rfc4648
- OWASP JWT Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/JSON_Web_Token_for_Java_Cheat_Sheet.html
JWTs lokal dekodieren
Header- und Payload-Claims im Browser. Nichts wird je hochgeladen.
Das Token lesen, das Token privat halten
Die Claims eines protokollierten JWT erklären den Fehler meist schneller als Code-Lektüre. Dekodieren Sie lokal, prüfen Sie die vier Standard-Claims und beheben Sie die Ursache statt des Symptoms.
Nutzen Sie den JWT-Dekoder – clientseitig, ohne Upload, sicher für Produktions-Tokens.