JWT-Debugger
Ein 401 mit einem Token, das gut aussieht, hat fast immer einen von sechs Gründen. Diese Seite zeigt Ihnen das Token so, wie der Server es liest – damit Sie herausfinden, welcher es ist.
Signieren Sie ein eigenes Token, um einen Endpunkt zu testen. Alles wird auf dieser Seite berechnet.
Schlüssel und fertiges Token bleiben in Ihrem Browser: Beides wird nirgendwohin gesendet und steht auch in keinem geteilten Link.
Prüfen Sie dieses Token in Ihrem eigenen Code. Das Snippet richtet sich nach dem Algorithmus im Header.
Ein abgelehntes JSON Web Token untersuchen
Tokens scheitern auf überschaubar viele Arten, und keine davon ist im Token selbst zu sehen – es sind drei Base64URL-Brocken mit Punkten dazwischen. Hier eingefügt wird daraus etwas, mit dem sich streiten lässt: jedes Header-Feld und jeder Claim in einer Tabelle, die sagt, wofür sie da sind, der Ablauf in Klartext übersetzt und die Signatur geprüft gegen den Schlüssel, den Sie haben.
Es wird beim Tippen dekodiert, und nichts wird irgendwohin gesendet. Auf einer solchen Seite gehört das deutlich gesagt, denn was Sie gleich einfügen, ist ein funktionierender Zugang zum Konto von jemandem.
Die sechs Fehler, in der Reihenfolge, die sich lohnt
| Was schiefging | Wie es hier aussieht | Abhilfe |
|---|---|---|
| Abgelaufen | Die Zeile über dem Header beginnt mit "Ist … abgelaufen" | Token erneuern; bei wenigen Sekunden die Uhren prüfen |
| Falsche Zielgruppe | aud nennt eine andere API | Das Token für die Zielgruppe anfordern, die die API erwartet |
| Falscher Aussteller | iss ist die Staging-URL statt der produktiven | Den Client auf den richtigen Aussteller richten – oder die API |
| Falscher Schlüssel | Prüfen meldet, dass die Signatur nicht stimmt | Den Schlüssel nehmen, mit dem der Aussteller signiert hat; auf Base64-Secrets achten |
| Falscher Algorithmus | Im Header steht ES256, Ihr Schlüssel ist ein RSA-Schlüssel | Schlüssel und Algorithmus neben dem Schlüsselfeld in Einklang bringen |
| Gar kein JWS | Die Seite nennt es ein JWE mit fünf Teilen | Der Payload ist verschlüsselt; lesen Sie ihn dort, wo der Entschlüsselungsschlüssel liegt |
Die Reihenfolge zählt. Ablauf und Zielgruppe brauchen weder Schlüssel noch fremde Mithilfe und sind in Sekunden ausgeschlossen; einem Signaturproblem nachzujagen, das sich als aud-Verwechslung entpuppt, kostet dagegen einen Nachmittag.
Lesen ist nicht Prüfen
An dieser Unterscheidung stolpern die meisten. Dekodieren sagt Ihnen, was ein Token behauptet; über die Echtheit sagt es nichts, denn Header und Payload sind kodiert, nicht verschlüsselt, und schreiben kann sie jeder. Prüfen heißt, die Signatur mit dem Secret oder dem öffentlichen Schlüssel des Ausstellers nachzurechnen – was diese Seite in Ihrem Browser tut –, und nur dieser Schritt macht aus einer Behauptung eine Tatsache.
Nutzen Sie die dekodierte Ansicht also, um eine Vermutung zu bilden, und die Schaltfläche Prüfen, um sie zu testen; und lassen Sie im eigenen Code nie eine Autorisierungsentscheidung auf dekodiertem Inhalt ruhen. Genau deshalb zeigt der Tab Code die serverseitige Prüfung in acht Sprachen. Wenn Sie die Kodierung selbst verwirrt, erklärt der Unterschied zwischen Base64 und Base64URL, warum sich ein JWT-Segment nicht einfach in einen gewöhnlichen Base64-Decoder einfügen lässt.
Was wie ein Token-Problem aussieht und keines ist
- Das Wort
Bearer, das beim Kopieren mitgekommen ist, oder ein Zeilenumbruch aus dem Terminal – beides verändert die signierte Eingabe und bricht die Signatur. - Ein Token, das ein Log-Viewer abgeschnitten hat. Das Signatur-Segment hat je Algorithmus eine feste Länge, ein gekürztes scheitert also immer.
- Zwei Dienste teilen sich ein Secret, und einer speichert es Base64-kodiert. Setzen Sie das Häkchen bei Secret ist Base64, um diese Seite nachzustellen.
- Ein
kid, das es nicht mehr gibt, weil der Aussteller seine Schlüssel gewechselt hat; das Token ist in Ordnung, der Schlüsselsatz ist veraltet.
Ist das Token selbst entlastet, bleiben die Verdächtigen auf dem Server: eine Middleware, die nie prüft, eine Uhr, die driftet, ein Cache mit einem alten Schlüsselsatz. Wenn Sie zum Testen ein Token in einem bekannten Zustand brauchen – abgelaufen, gültig, mit einem Schlüssel Ihrer Wahl signiert –, baut der JWT-Generator es, und der Ablauf-Prüfer erklärt, wie ein Prüfer die Zeit-Claims liest.