JWT-Decoder meldet ungültiges Token – was tun? Zuerst die Schlussfolgerung
Wenn der JWT-Decoder einen Fehler meldet, ändern Sie nicht sofort den Code. Über neunzig Prozent der „ungültigen Token“ sind kein Problem des Verschlüsselungsalgorithmus, sondern das Token selbst ist unvollständig, beim Einfügen wurden zusätzliche Zeichen eingemischt, oder Sie haben „Dekodieren“ mit „Validieren“ verwechselt. Gehen Sie in der folgenden Reihenfolge vor, dann lässt sich das Problem meist in wenigen Minuten lokalisieren.
Der JWT-Decoder ist nur ein lokales Analysewerkzeug. Er stellt die drei Abschnitte des Tokens in lesbare Header und Payload wieder her. Er validiert keine Signatur und prüft nicht, ob das Token abgelaufen ist.
JWT-Decoder verwenden: In drei Schritten zur Analyse
Ein gültiges JWT besteht aus drei Abschnitten, getrennt durch zwei englische Punkte: Header, Payload, Signatur. Fehlt einer dieser Abschnitte, schlägt die Analyse fehl.
- Holen Sie sich den vollständigen Token-String, der normalerweise im
Authorization-Feld des Request-Headers steht, im FormatBearer. - Entfernen Sie das
Bearer-Präfix und überflüssige Leerzeichen, behalten Sie nur den Token selbst. - Fügen Sie ihn in den JWT-Decoder ein. Das Tool stellt Header und Payload lokal im Browser wieder her.
Im Analyseergebnis sehen Sie Felder wie alg, exp, sub. exp ist der Ablaufzeitstempel in Sekunden.
Häufige Fehlbedienungen bei der Verwendung des JWT-Decoders
Der häufigste Fehler ist, den gesamten Request-Header einzufügen, einschließlich Bearer und Zeilenumbrüchen. Zeilenumbrüche sind mit bloßem Auge unsichtbar, lassen aber die base64url-Dekodierung direkt fehlschlagen.
Der zweite Fehler ist, beim Kopieren das Ende abzuschneiden. Token sind sehr lang, Chat-Software und Terminals fügen oft in der Mitte Zeilenumbrüche oder Auslassungspunkte ein.
Der dritte Fehler ist die Verwendung von formatiertem Rich-Text beim Einfügen, wobei Anführungszeichen automatisch in chinesische Vollbreitenzeichen umgewandelt werden.
JWT-Decoder meldet Fehler – was tun: Nach diesen fünf Ursachenkategorien suchen
Im Folgenden nach Häufigkeit von hoch nach niedrig sortiert. Sie können Punkt für Punkt abgleichen.
- Falsche Anzahl an Abschnitten: Das Token muss genau zwei Punkt-Trennzeichen haben. Eines mehr oder weniger führt zu einem Fehler.
- Ungültiger Zeichensatz: base64url erlaubt nur Buchstaben, Ziffern,
-und_. Bei+,/,=oder Leerzeichen ist Vorsicht geboten. - Leerzeichen: Führende und nachfolgende Leerzeichen, Tabulatoren und Zeilenumbrüche zerstören die Analyse.
- Token abgeschnitten: Die Länge ist offensichtlich zu kurz, oder das Ende ist kein vollständiger Abschnitt.
- Inhalt ist selbst kein JWT: Zum Beispiel geben manche Schnittstellen ein undurchsichtiges Token zurück, das gar nicht analysiert werden kann.
Warum das Entfernen des Bearer-Präfixes die meisten Fehler behebt
Weil der Decoder ein reines Token benötigt, während Bearer Teil des Übertragungsprotokolls ist und nicht zur Token-Struktur gehört. Wenn beides vermischt wird, ist der erste Abschnitt kein gültiger base64url-String mehr.
Wenn Sie beim API-Debugging mit dem JWT-Decoder wiederholt auf Fehler stoßen, empfiehlt es sich, den ursprünglichen String zuerst in einer reinen Textdatei zu speichern, führende und nachfolgende Leerzeichen zu entfernen und dann einzufügen. So lassen sich Störungen durch automatische Zeilenumbrüche des Editors ausschließen.
Unterschied zwischen JWT-Decoder und Validierung
Dies ist der am leichtesten zu verwechselnde Punkt und die Ursache vieler „Fehlalarme“.
Dekodieren stellt lediglich die base64url-Kodierung in Klartext wieder her. Jeder String, der dem Format entspricht, kann dekodiert werden, ohne Schlüssel. Validieren hingegen prüft, ob die Signatur von der Partei erzeugt wurde, die den Schlüssel besitzt, und überprüft Ablaufzeit, Aussteller, Empfänger und andere Claims.
Daher bedeutet erfolgreiches Dekodieren nicht, dass das Token gültig ist. Ein manipuliertes Token lässt sich trotzdem dekodieren, aber die Validierung schlägt definitiv fehl.
Umgekehrt deutet ein fehlgeschlagenes Dekodieren meist darauf hin, dass die Daten bei der Übertragung oder beim Kopieren beschädigt wurden, nicht dass die Signatur ein Problem hat. Diese beiden Dinge zu unterscheiden, spart Ihnen viel Fehlersuche.
JWT-Decoder große Dateien: Wie mit sehr langen Token umgehen
JWT hat selbst eine Größenobergrenze, aber wenn die Payload mit vielen benutzerdefinierten Claims gefüllt wird, wird das Token sehr lang. Dies kommt häufig bei Szenarien mit Berechtigungslisten oder Benutzerprofilen vor.
Lange Token bringen zwei Probleme mit sich. Erstens werden sie beim Kopieren leicht von Tools automatisch umgebrochen, zweitens schneiden manche Terminals und Log-Systeme überlange Strings ab.
Empfehlungen zur Handhabung:
- Schreiben Sie das Token zunächst mit einem Befehl oder Skript in eine Datei und prüfen Sie dann abschnittsweise, ob es vollständig ist.
- Stellen Sie sicher, dass keine Zeilenumbrüche eingemischt sind. Viele Fehler haben hier ihre Ursache.
- Wenn die Payload tatsächlich zu groß ist, erwägen Sie, Claim-Felder zu reduzieren und nur notwendige Informationen zu behalten.
Zu beachten ist: Je länger das Token, desto größer der zusätzliche Aufwand bei jeder Anfrage. Das ist nicht nur ein Dekodierungsproblem, sondern beeinflusst auch die API-Leistung.
JWT-Decoder auf dem Handy: Wichtige Punkte zur Fehlersuche auf Mobilgeräten
Bei der Fehlersuche mit Token auf dem Handy liegen die Schwierigkeiten hauptsächlich beim Kopieren und Einfügen.
Die Langdruck-Auswahl auf Mobilgeräten lässt leicht einige Zeichen am Anfang oder Ende aus. Verwenden Sie besser „Alles auswählen“ statt manuelles Ziehen des Auswahlrahmens.
Außerdem ersetzen manche Eingabemethoden automatisch englische Anführungszeichen durch chinesische oder fügen nach Großbuchstaben automatisch Leerzeichen ein. Wechseln Sie vor dem Einfügen in den englischen Eingabemodus.
Wenn Ihre Tool-Seite auch auf Mobilgeräten korrekt gerendert wird, können Sie direkt einfügen. Der Analyseprozess erfolgt lokal, das Token verlässt Ihr Gerät nicht. Dies ist besonders wichtig bei der Fehlersuche mit Produktions-Token.
Häufige Fragen
Dekodierung erfolgreich, aber die Schnittstelle gibt weiterhin 401 zurück – ist das ein Problem des Decoders
Nein. 401 bedeutet normalerweise, dass die serverseitige Validierung fehlgeschlagen ist. Die Ursache kann eine nicht übereinstimmende Signatur, ein abgelaufenes Token oder eine Nichtübereinstimmung von Aussteller und Empfänger sein. Der Decoder ist nur für die Wiederherstellung des Inhalts zuständig und nimmt nicht an der Validierung teil.
Warum erscheinen im Token unlesbare Zeichen
Meist ist der Zeichensatz ungültig oder es sind versteckte Zeichen vorhanden. base64url verwendet einen sehr engen Zeichenbereich. Sobald Leerzeichen, Zeilenumbrüche oder Vollbreitenzeichen eingemischt werden, ist das Ergebnis unlesbar.
Warum ließ sich dasselbe Token gestern dekodieren und heute nicht
Der Token-String selbst ändert sich nicht. Wahrscheinlicher ist, dass der diesmal kopierte Inhalt anders ist als beim letzten Mal, zum Beispiel mit zusätzlichem Zeilenumbruch, oder dass sich die von der Quellschnittstelle zurückgegebenen Felder geändert haben.
Kann der Decoder den zur Signatur gehörenden Schlüssel sehen
Nein. Die Signatur ist das Ergebnis einer Einwegoperation, aus der sich der Schlüssel nicht zurückrechnen lässt. Jede Behauptung, man könne aus einem Token den Schlüssel wiederherstellen, ist unglaubwürdig.
Wie liest man die Ablaufzeit
exp und iat sind Unix-Zeitstempel in Sekunden und müssen in ein Datum umgerechnet werden, um sie zu vergleichen. Beachten Sie, dass sie UTC-Zeit angeben.
Abschluss
Bei der Fehlersuche, wenn der JWT-Decoder einen Fehler meldet, gibt es im Kern drei Schritte: Bestätigen, dass das Token vollständig ist, Nicht-Token-Zeichen entfernen, Dekodieren und Validieren unterscheiden. Wenn Sie diese drei Dinge solide umsetzen, verschwinden die allermeisten Fehler. Wenn Sie schnell verifizieren möchten, können Sie mit einem im Browser lokal laufenden Tool den Token-Inhalt schnell wiederherstellen. Der Fehlersuche-Prozess erfordert kein Hochladen von Daten.