Dekodieren Sie JWT-Tokens lokal mit unserem JWT-Decoder. Ihr Token verlässt nie Ihren Browser.
Warum JWTs in CI ständig auftauchen
Integrationstests, End-to-End-Suiten und Deployment-Skripte brauchen oft ein Zugriffstoken. Schlägt ein Test fehl, landet das Token im Log – und der nächste Schritt ist, hineinzuschauen.
Das Dekodieren eines JWT ist sicher: Header und Payload sind nur base64url-kodiert, nicht verschlüsselt. Das Risiko liegt nicht im Dekodieren, sondern darin, das Token – oder schlimmer den Signaturschlüssel – in ein Server-Tool einzufügen, das es protokolliert.
Die meisten Token-Fehler in CI lassen sich auf wenige Ursachen zurückführen. Das Token lief ab, während der Job in der Warteschlange stand, die Uhr des Runners weicht von der des Ausstellers ab, oder das Token wurde für eine andere Umgebung ausgestellt. Das Dekodieren zeigt in unter einer Minute, um welche Ursache es sich handelt.
JWT-Aufbau in 60 Sekunden
Die drei Teile sind durch Punkte getrennt, und jeder Teil ist base64url ohne Auffüllung kodiert. Deshalb wirkt ein JWT wie eine Kette aus Buchstaben, Ziffern und Bindestrichen und nicht wie lesbares JSON.
| Teil | Inhalt | Beispiel |
|---|---|---|
| Header | Algorithmus und Tokentyp | "alg": "RS256" |
| Payload | Claims wie sub, exp, iat, iss | "exp": 1780000000 |
| Signatur | Schlüssel-Hash zur Integritätsprüfung | base64url-kodierte Bytes |
Hinweis: Nur die Signatur benötigt den Schlüssel. Header und Payload lassen sich immer ohne Geheimnis dekodieren.
Ein CI-Token sicher dekodieren
- Kopieren Sie das Token aus dem CI-Log, ohne umliegende Geheimnisse oder Umgebungszeilen.
- Öffnen Sie den JWT-Decoder in Ihrem Browser.
- Fügen Sie das Token ein und prüfen Sie den Header: alg- und kid-Werte.
- Prüfen Sie den Payload: exp, iat, iss und sub gegen die Umgebung, die Sie debuggen.
- Vergleichen Sie exp mit der aktuellen Zeit über den Zeitstempel-Konverter, falls Werte mehrdeutig sind.
Warnung: Fügen Sie niemals den Signaturschlüssel, das Client-Secret oder ein Refresh-Token in ein Tool ein. Das Dekodieren des Tokens reicht für 90 % der Auth-Fehler.
Häufige JWT-Probleme in CI
- Abgelaufenes Token: exp liegt in der Vergangenheit, oft weil der Test länger lief als die Token-Lebensdauer
- Clock Skew: ausstellender Server und Test-Runner weichen zeitlich ab
- Falscher Aussteller: Token wurde für eine andere Umgebung erstellt
- Algorithm-Confusion: alg im Header passt nicht zum Schlüsseltyp
- Fehlerhafte Eingabe: Leerzeichen oder URL-kodierte Zeichen brechen das base64url-Parsing
- Falsche Zielgruppe: aud passt nicht zu dem, was die API erwartet, die Anfrage wird trotz gültiger Signatur abgelehnt
- nbf in der Zukunft: Das Token ist noch nicht nutzbar, weil der Beginn der Gültigkeit noch nicht erreicht ist
FAQ
Q.Ist das Dekodieren eines JWT sicher?
A.Ja. Header und Payload eines JWT sind base64url-kodiert, nicht verschlüsselt; beim Dekodieren sehen Sie nur, was ohnehin im Token stand. Jeder, der das Token besitzt, kann es dekodieren – das ist beabsichtigt. Gefährlich sind das Teilen des Tokens und ein Eintrag in öffentlichen Logs.
Q.Kann ein Decoder die JWT-Signatur prüfen?
A.Nein – ein Decoder besitzt keinen Schlüssel, und die Verifikation erfordert den Signaturschlüssel oder den passenden öffentlichen Schlüssel. Was ein Decoder kann, ist das Parsen von Header und Payload, damit Sie alg, kid und die Claims prüfen können. Für echte Verifikation nutzen Sie den Validierungs-Endpunkt Ihres Identity Providers oder eine JWT-Bibliothek mit dem öffentlichen Schlüssel.
Q.Was sollte ich niemals in ein Debugging-Tool einfügen?
A.Private Schlüssel, Client-Secrets, Refresh-Tokens und Tokens mit Zugriff auf Produktionsdaten gehören in kein Tool. Enthält der Payload Angaben, die Sie nicht weitergeben möchten, redigieren Sie sie vor dem Einfügen, und verwenden Sie einen clientseitigen Decoder, dessen Eingabe Ihren Rechner nie verlässt.
Q.Warum steht exp als nackte Zahl im Token?
A.Weil exp eine NumericDate ist: Sekunden seit dem 1. Januar 1970 UTC. Ein Wert wie 1780000000 sagt auf den ersten Blick nichts aus; der JWT-Decoder zeigt ihn deshalb auch als lesbares Datum an. Zum Vergleich mit der aktuellen Zeit nutzen Sie den Zeitstempel-Konverter oder lassen das Tool rechnen.
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 8725 – Best Current Practices für JSON Web Tokens: https://www.rfc-editor.org/rfc/rfc8725
- OWASP – JSON Web Token Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/JSON_Web_Token_for_Java_Cheat_Sheet.html
Token lesen, bevor Sie den Test verdächtigen
Prüfen Sie alg, exp und iss mit dem JWT-Decoder, rechnen Sie Zeitstempel mit dem Zeitstempel-Konverter um und vergleichen Sie mit der Umgebung, in der der Test läuft.
Lassen Sie Signaturschlüssel und Produktionstokens vollständig aus Logs und Einfüge-Tools heraus.
Als ich einen wiederkehrenden Token-Fehler in einer nächtlichen Pipeline untersucht habe, war das Dekodieren der Schritt, der das Rätselraten beendete. Der Payload zeigte ein exp, das bereits abgelaufen war, als die Warteschlange den Job aufnahm: Das Token wurde zur Build-Zeit erstellt, nicht zur Laufzeit, und war damit schon vor dem ersten Einsatz ungültig.