Fügen Sie ein JWT ein, um Header und Claims zu sehen. Ablauf- und Ausstellungszeiten werden in lesbare Daten umgewandelt, registrierte Claims sind erklärt. Das Token bleibt in Ihrem Browser.
Läuft vollständig im Browser. Diese Seite ist eine statische Datei. Was Sie eingeben, bleibt im Tab, wird nie an einen Server geschickt und ist beim Schließen verschwunden — ein echtes Token oder eine echte Konfiguration einzufügen ist also unbedenklich.
Header, Payload und Signatur, durch Punkte getrennt.
exp zählt Sekunden seit der Unix-Epoche, nicht Millisekunden. Ein Wert in Millisekunden landet im Jahr 55000 und ist ein häufiger Fehler.
Bibliotheken, die alg: none befolgen, akzeptieren gefälschte Tokens. Legen Sie den erwarteten Algorithmus serverseitig fest.
Ein JWT ist signiert, nicht verschlüsselt. Wer das Token hat, liest jeden Claim — genau wie diese Seite. Packen Sie nie Vertrauliches hinein.
Dekodieren beweist nichts über Echtheit. Ein Token kann perfekt lesbar und vollständig gefälscht sein; nur die Signaturprüfung auf Ihrem Server klärt das.
Läuft ein Token „sofort“ ab, vergleichen Sie den iat-Claim mit Ihrer Serveruhr. Wenige Minuten Versatz zwischen Maschinen weisen ansonsten gültige Tokens zurück.
Nein. Die Seite ist statisch, und die Dekodierung passiert in Ihrem Browser über Base64 und einen JSON-Parse. Nichts wird protokolliert oder übertragen, was Sie im Netzwerk-Panel nachprüfen können.
Die Prüfung braucht das Signaturgeheimnis oder den öffentlichen Schlüssel des Ausstellers. Ein Produktiv-Signaturgeheimnis in eine Webseite einzufügen wäre eine weit schlechtere Angewohnheit als jede Bequemlichkeit, die es bringt.
exp ist der Zeitpunkt, ab dem das Token nicht mehr akzeptiert wird; nbf der, ab dem es akzeptiert wird. Ein im Voraus ausgestelltes Token kann ein nbf in der Zukunft haben und wird bis dahin abgelehnt.