JWT-Decoder: Was ist in einem Token enthalten und was nicht

Die drei Teile

• Header – der Signaturalgorithmus (`alg`) und der Token-Typ (`typ`), zum Beispiel HS256.
• Nutzlast – die Ansprüche: um wen es sich bei dem Token handelt, wann er ausgegeben wurde und wann er abläuft.
• Signatur – wird über die ersten beiden Segmente mit dem Schlüssel des Ausstellers berechnet, weshalb ein Decoder ihn zwar anzeigt, aber nicht überprüfen kann.

                eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 . eyJzdWIiOiIxMjMiLCJleHAiOjE3NjAwMDAwMDB9 . signature
           header                            payload                       signature
              

Die Behauptungen, die die meisten Fehler erklären

• `exp` (Ablauf) – die häufigste Ursache für einen 401. Ein Token, der vor zwei Minuten abgelaufen ist, wird abgelehnt, bevor irgendetwas anderes untersucht wird.
• `nbf` (nicht vorher) – das Spiegelbild: ein Token, das verwendet wird, bevor sein Gültigkeitsfenster abgelehnt wird.
• `iat` (ausgestellt am) – nützlich, um herauszufinden, wie alt eine Sitzung ist, und um Uhren zu erkennen, die nicht übereinstimmen.
• `aud` (Zielgruppe) und `iss` (Aussteller) – Nichtübereinstimmungen bedeuten hier, dass das Token gültig ist, aber für einen anderen Dienst ausgestellt wurde, was auf verwirrende Weise fehlschlägt.

Zeitangaben sind UTC-Sekunden seit der Unix-Epoche. Wenn ein Token gültig aussieht, aber viel zu früh oder zu spät abläuft, prüfen Sie, ob ein Uhrproblem oder eine Nutzlast vorliegt, die Millisekunden enthält, wo Sekunden erwartet wurden.

Warum Sie `alg` niemals blind vertrauen sollten

Zwei Angriffe sind alt genug, um berühmt zu sein und tauchen immer noch in freier Wildbahn auf. Der `none`-Algorithmus teilt dem Verifizierer mit, dass überhaupt keine Signatur vorhanden ist; Ein Server, der den Header liest, anstatt seinen eigenen erwarteten Algorithmus durchzusetzen, akzeptiert ihn. Und bei der RSA/HS-Verwirrung signiert ein Angreifer mit dem öffentlichen Schlüssel als HMAC-Geheimnis und betrügt so einen Server, der beide Familien akzeptiert. Die Verteidigung liegt in beiden Fällen im Verifizierer, nicht im Decoder: Fixieren Sie den erwarteten Algorithmus serverseitig und leiten Sie ihn niemals vom Token selbst ab.

Immer lokal dekodieren

Ein JWT ist ein Berechtigungsnachweis: Wer ihn besitzt, kann bis zum Ablauf als Benutzer fungieren. Das Einfügen einer echten URL in eine Website, die sie auf einem Server postet, führt zu einer Live-Sitzung ohne Nutzen, da es sich bei der Dekodierung um eine Base64-URL-Arithmetik handelt, die jeder Browser in Mikrosekunden ausführen kann. Der YamlBox JWT-Decoder analysiert das Token auf der Seite, zeigt die Zeitstempelansprüche als lesbare UTC-Daten an und arbeitet bei deaktiviertem Netzwerk weiter – der einzige Decodertyp, der sich für einen Produktionstoken lohnt.

Eine Debugging-Routine, die funktioniert

1. Dekodieren und lesen Sie zuerst `exp` – die Hälfte aller Meldungen über „ungültige Token“ enden hier.
2. Vergleichen Sie `aud` und `iss` mit den Erwartungen von API und dann `nbf` auf Taktversatz.
3. Vergleichen Sie die entschlüsselten Ansprüche mit den Annahmen Ihres Codes zu Rollen oder Bereichen.
4. Wenn die Behauptungen richtig aussehen und es trotzdem fehlschlägt, liegt das Problem an der Verifizierung – falscher Schlüssel, rotiertes Geheimnis oder eine Nichtübereinstimmung des Algorithmus.