Was ein JWT-Decoder sichtbar macht
Ein signiertes JSON Web Token im kompakten Format besteht normalerweise aus drei durch Punkte getrennten Teilen: Header, Nutzdaten und Signatur. Dieser Decoder liest die ersten beiden Base64url-Teile als UTF-8-JSON und zeigt ihre Angaben an. Den dritten Teil überprüft er nicht. Das Zurückwandeln einer Kodierung beweist weder, wer das Token ausgestellt hat, noch, ob es unverändert ist oder ein Server es akzeptiert. Im Header können Algorithmus und Tokentyp stehen. Die Nutzdaten können Aussteller, Zielgruppe, Subjekt und anwendungsspezifische Ansprüche enthalten. Behandeln Sie alle angezeigten Angaben als nicht vertrauenswürdig, bis ein Verifizierer die geltenden Regeln angewendet hat. Die Eingabe bleibt während der Berechnung im Browser.
Zeitangaben exp, nbf und iat lesen
JWT-Zeitangaben wie exp, nbf und iat verwenden NumericDate-Werte in Sekunden seit Beginn der Unix-Epoche. Die Zahl 2.000.000.000 steht für Sekunden, nicht für Millisekunden. Der Decoder zeigt neben dem Rohwert ein lesbares UTC-Datum an. Damit lassen sich abgelaufene, noch nicht gültige oder unerwartet ausgestellte Tokens untersuchen. Das Datum ist nur die Auslegung einer Behauptung aus den Nutzdaten, kein Ergebnis einer Gültigkeitsprüfung. Fügen Sie das Beispieltoken ein und vergleichen Sie exp mit dem UTC-Wert. Schreibt eine Anwendung versehentlich eine dreizehnstellige Millisekundenzahl, erscheint ein unplausibel fernes oder nicht nutzbares Datum. Korrigieren Sie den Erzeuger statt blind zu teilen. Verwenden Sie UTC beim Vergleich mit Serverprotokollen.
Ein sinnvoller Diagnoseablauf
Nehmen Sie ein Testtoken aus einer kontrollierten Entwicklungsumgebung und prüfen Sie, ob Aussteller, Zielgruppe und Subjekt den Erwartungen entsprechen. Vergleichen Sie exp und nbf mit dem Zeitpunkt der fehlgeschlagenen Anfrage. Stimmen die Nutzdaten, obwohl der Server ablehnt, untersuchen Sie dort Signaturprüfung, Schlüsselauswahl und Anwendungsregeln. Der Decoder kann nicht entscheiden, ob der Server das Token annehmen müsste. Nutzdaten sind nur kodiert und nicht verschlüsselt; jede Person mit dem Token kann Namen und private Felder lesen. Veröffentlichen Sie echte Zugriffstokens daher nicht in Fehlermeldungen, Bildschirmfotos, URLs oder Beispielen. Selbst bei lokaler Verarbeitung kann das Kopieren des Ergebnisses Informationen preisgeben.
Grenzen und typische Fehler
Ein verschlüsseltes JWE mit fünf Teilen liegt außerhalb des Bereichs dieses Decoders für signierte dreiteilige Tokens. Fehlerhafte Base64url-Segmente, ungültiges UTF-8 und ein JSON-Header, der kein Objekt ist, werden abgewiesen statt stillschweigend repariert. Das Werkzeug lädt keine Schlüssel, verifiziert keine JWS-Signatur, prüft keine erlaubten Algorithmen, vergleicht keine erwartete Zielgruppe und setzt keine Zeitabweichung durch. Dafür ist eine korrekt eingerichtete Validierungsbibliothek nötig. Leiten Sie aus einem angezeigten admin-Feld keine Berechtigung ab: Ein manipuliertes Token kann bei ungültiger Signatur trotzdem überzeugende Rollen anzeigen. Auch ein künftiges exp-Datum genügt nicht, wenn Aussteller, Zielgruppe, Widerruf oder andere Regeln nicht passen.