Fügen Sie ein Token ein oder erzeugen Sie eines aus Payload und Testgeheimnis. Eine gültige Signatur ersetzt keine Prüfung von Issuer, Audience und Berechtigung.
Läuft lokal in deinem BrowserInspect a token to view its header.
Inspect a token to view its payload.
Das Geheimnis wird ausschließlich von der Kryptografie-API des Browsers verwendet. Der Verifier unterstützt HS256, HS384 und HS512 und sendet weder Token noch Geheimnis an VoriTools.
Erzeugen Sie nur HS256-, HS384- oder HS512-Tokens. Payload und Geheimnis bleiben in Web Crypto; dieses Werkzeug bietet niemals alg: none.
Generate a local HMAC JWT to view it here.
Dekodierte Claims sind lesbare Base64URL-Daten, aber kein Vertrauensnachweis. Prüfen Sie Algorithmus, Ablaufzeit, vorgesehenen Issuer und Audience und verifizieren Sie die Signatur mit einem vertrauenswürdigen Schlüssel oder Geheimnis.
Diese Seite zerlegt ein kompaktes JWT in Header, Payload und Signatur, zeigt die dekodierten Claims und prüft die Signatur, wenn das Token HMAC-signiert ist und Sie das Secret eingeben. Außerdem erzeugt sie kurzlebige HS256-, HS384- oder HS512-Token aus einer Payload, die Sie selbst schreiben.
Dekodieren und Prüfen sind bewusst zwei Schritte. Den Payload eines JWT kann jeder ohne Schlüssel lesen, und eine gültige Signatur belegt nur, dass das Token mit diesem Schlüssel signiert wurde; ob es abgelaufen ist, für Ihren Dienst ausgestellt wurde oder etwas erlaubt, sagt sie nicht.
Der Header ist Base64URL-kodiertes JSON und nennt normalerweise alg und typ, manchmal eine kid, die dem Prüfer sagt, welcher Schlüssel gehört. Der Payload ist die Claim-Menge: registrierte Claims wie iss, sub, aud, exp, nbf, iat und jti plus die privaten Claims des Ausstellers. Die Signatur ist der Algorithmus über die ASCII-Zeichenkette base64url(header) + "." + base64url(payload) mit dem Schlüssel.
Base64URL ist das normale Base64-Alphabet mit - und _ statt + und / und ohne Auffüllzeichen. Deshalb passt ein Token ohne Escaping in eine URL, ein Cookie oder einen Authorization-Header – und deshalb zerstört handisches Zusammensetzen meist die Signatur.
Nur die HMAC-Familie: HS256, HS384 und HS512, weil ein gemeinsames Secret zum Nachrechnen genügt. RS256, PS256, ES256 und EdDSA signieren mit privatem und prüfen mit öffentlichem Schlüssel; hier lassen sie sich dekodieren, aber nicht prüfen – dafür brauchen Sie die öffentliche JWK des Ausstellers. Bei einem RS256-Token bleibt die Schaltfläche Signatur prüfen deaktiviert, und der Hinweis erklärt warum.
Ein Token, das alg als none angibt, wird rot markiert: Es darf nie akzeptiert werden, und ein Prüfer sollte sich nie auf den im Token genannten Algorithmus verlassen, ohne ihn gegen eine Erlaubnisliste zu prüfen. HS256 für RS256 einzusetzen und mit dem öffentlichen Schlüssel wie mit einem HMAC-Secret zu signieren, ist ein bekannter Angriff auf nachlässige Bibliotheken.
exp muss in der Zukunft, nbf in der Vergangenheit liegen, jeweils in Sekunden seit der Unix-Epoche und mit etwas Toleranz zwischen Uhren. iat sollte plausibel und nicht in der Zukunft sein. iss und aud müssen zu Ihrem Dienst passen, sonst wird ein für eine andere Anwendung ausgestelltes Token akzeptiert.
Eine bestätigte Signatur ist keine Berechtigung. Rollen, Scopes und Mandantenkennungen stecken in privaten Claims, und der Claim-Satz eines JWT ist signiert, nicht verschlüsselt: Legen Sie kein Geheimnis in eine Payload, die Sie dem Inhaber des Tokens nicht zeigen würden.
Dekodierung und HMAC-Prüfung laufen in Ihrem Browser, das Token wird also nicht hochgeladen. Trotzdem bleibt die sichere Gewohnheit, mit Wegwerf-Token zu testen: ein Produktions-Refresh-Token oder eine langlebige Zugangsdaten sollten in keine Webseite eingefügt werden, auch nicht in diese.
Diese Verfahren sind asymmetrisch, und diese Seite rechnet nur HMAC-Signaturen nach. Das Token lässt sich weiterhin dekodieren und seine Claims lesen, doch zum Prüfen braucht man den öffentlichen Schlüssel des Ausstellers und eine JWA-fähige Bibliothek – das kann eine Browserseite mit nur einem gemeinsamen Secret nicht korrekt leisten.
Entweder ist das Secret falsch, oder der gewählte Algorithmus passt nicht zu dem im Header, oder der Token-Text wurde nach dem Signieren verändert. Payload bearbeiten, neu einrücken und von Hand neu kodieren führt zum gleichen Ergebnis, weil die Signatur die exakten Originalbytes abdeckt.
Weil ein JWT signiert und nicht verschlüsselt ist. Base64URL ist eine Kodierung, und wer das Token hat, dekodiert Header und Payload ganz ohne Schlüssel. Sind die Claims selbst sensibel, nutzen Sie JWE, das den Inhalt für einen Empfänger verschlüsselt.
JWT ist die Claim-Menge, also die Daten. JWS ist die signierte Serialisierung, die das kompakte Drei-Teile-Token dieser Seite erzeugt. JWE ist die verschlüsselte Serialisierung, bei der sich der Payload ohne Schlüssel nicht lesen lässt und die Struktur fünf statt drei Teile hat.
Minuten statt Stunden. Setzen Sie Ablauf in Minuten klein, damit ein geleaktes Test-Token schnell ungültig wird, und bedenken Sie: Diese Seite signiert mit dem lokal eingegebenen Secret, das Token gilt also nur in Systemen mit demselben Secret.