Ein JWT besteht aus drei Base64-URL-Segmenten: einem Header mit dem Namen des Signaturalgorithmus, einer Nutzlast mit Ansprüchen und einer Signatur. Die ersten beiden Segmente sind nicht verschlüsselt – jeder, der das Token besitzt, kann sie lesen – daher benötigt man zum Dekodieren weder einen Schlüssel noch einen Server. Dies geschieht direkt auf der Seite: Anhand des Ablaufdatumsanspruchs wird geprüft, ob das Token noch gültig ist, und die Zeitstempel werden als Datumsangaben dargestellt.
Die Dekodierung erfolgt in Ihrem Browser, und das Token wird niemals über das Netzwerk übertragen. Das ist hier wichtiger, als es zunächst klingt: Ein JWT ist ein gültiges Berechtigungszertifikat, und das Einfügen eines Produktionstokens in ein Tool, das es an einen Server sendet, stellt eine Offenlegung der Zugangsdaten dar. Laden Sie diese Seite, trennen Sie die Verbindung, und sie funktioniert weiterhin.
Die Signatur wird nicht überprüft, und kein Decoder, der nur das Token besitzt, kann das. Zur Verifizierung wird der Signaturschlüssel benötigt, und genau diesen werden Sie sicher nicht auf einer Webseite einfügen. Lesen Sie die Ausgabe als "this is what the token claims" , nicht als "this token is genuine" – jeder kann ein JWT erstellen, das sich problemlos dekodieren lässt und ohne jegliche Signatur auskommt.
„exp“ steht für Ablaufdatum und „iat“ für Ausstellungszeitpunkt, jeweils in Sekunden seit dem 1. Januar 1970 (Unix-Epoche) und nicht in Millisekunden. Letzteres ist die Abweichung von 1000 Millisekunden, die bei den meisten ersten Versuchen zu Fehlern führt. „sub“ ist das Subjekt, „aud“ die Zielgruppe und „iss“ der Aussteller. Ein Token, das für eine andere Zielgruppe gültig ist, kann häufig zu einem 401-Fehler führen. Gültigkeitsbereiche und Rollen sind Konventionen, keine Standards, daher werden sie unter dem vom Aussteller gewählten Namen angezeigt.
Alle Werkzeuge · Einstiegsanleitung · Alle 39 Mock-REST-APIs
Zuletzt aktualisiert