So entschlüsseln Sie ein JWT und prüfen seine Ansprüche sicher
Schnelle Antwort
Ein JWT besteht aus drei Base64URL-Strings, die durch Punkte verbunden sind: header.payload.signature. Dekodieren Sie den Header und die Nutzlast mit der Base64URL-Dekodierung, um Ansprüche zu prüfen. Bei der Dekodierung werden jedoch nur die Daten gelesen, die Authentizität wird nicht überprüft. Überprüfen Sie immer die Signatur auf dem Server, bevor Sie einem Anspruch vertrauen. Verwenden Sie unseren JWT Decoder, um Token in Ihrem Browser zu überprüfen.
Einführung
Ein JSON Web Token (JWT, RFC 7519) ist ein kompaktes, URL-sicheres Tokenformat, das zur Authentifizierung und Autorisierung verwendet wird. Es besteht aus drei Base64URL-codierten Teilen, die durch Punkte getrennt sind: header.payload.signature. Der Header beschreibt den Algorithmus, die Nutzlast enthält Ansprüche (Benutzer-ID, Rollen, Ablauf) und die Signatur beweist, dass das Token von einer vertrauenswürdigen Partei ausgestellt wurde. Entscheidend ist, dass der Header und die Nutzdaten codiert und nicht verschlüsselt sind – jeder kann sie lesen.
Schritt für Schritt
-
Teilen Sie den Token in drei Teile
Ein JWT sieht aus wie xxxxx.yyyyy.zzzzz. Teilen Sie das Punktzeichen auf, um den Header (Teil 0), die Nutzlast (Teil 1) und die Signatur (Teil 2) zu erhalten. Wenn es nicht genau drei Teile gibt, ist das Token fehlerhaft.
-
Base64URL-Dekodierung des Headers
Der Header ist ein Base64URL-codiertes JSON-Objekt wie {"alg": "HS256", "typ": "JWT"}. Base64URL verwendet - und _ anstelle von + und / und lässt Auffüllungen weg. Dekodieren Sie es, dann JSON.parse, um den Algorithmus zu lesen und einzugeben. Unser JWT Decoder erledigt dies automatisch.
-
Base64URL-Dekodierung der Nutzlast (Ansprüche)
Die Nutzlast ist ein JSON-Objekt von Ansprüchen. Zu den registrierten Ansprüchen gehören iss (Aussteller), sub (Betreff), aud (Zielgruppe), exp (Ablauf), nbf (nicht vorher), iat (ausgestellt am) und jti (Token-ID). Private Ansprüche sind anwendungsspezifisch (z. B. Rolle, E-Mail). Entschlüsseln und prüfen Sie, aber vertrauen Sie nicht, bis es überprüft wurde.
-
Überprüfen Sie die Verfalls- und Nichtverjährungsansprüche
exp und nbf sind Unix-Zeitstempel (Sekunden). Wenn die aktuelle Zeit nach exp liegt, ist das Token abgelaufen und muss abgelehnt werden. Liegt die aktuelle Zeit vor nbf, ist der Token noch nicht gültig. Überprüfen Sie diese clientseitig auf UX, erzwingen Sie sie jedoch aus Sicherheitsgründen serverseitig.
-
Überprüfen Sie die Signatur auf dem Server (niemals clientseitig)
Die Signatur ist HMAC-SHA256(secret, header.payload) für HS256 oder RSA/ECDSA Signatur für RS256/ES256. Für die Verifizierung ist der geheime oder öffentliche Schlüssel erforderlich, der niemals den Browser erreichen darf. Verwenden Sie zur Überprüfung eine Bibliothek wie jsonwebtoken (Node) oder Jose – schreiben Sie niemals Ihre eigene Krypto.
Beispiele
Ein typischer JWT (drei Teile)
Eingang: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpmeJf36POk6yJV_adQssw5c
Ausgabe: Header: {"alg":"HS256","typ":"JWT"} Payload: {"sub":"1234567890","name":"John Doe","iat":1516239022}
Entschlüsselte Nutzlast mit Standardansprüchen
Eingang: Nutzlast eines echten Authentifizierungstokens
Ausgabe: {"sub":"user-42","iss":"freeonlinetoolsgo.com","exp":1767229200,"iat":1767225600,"role":"admin"}
Erkennung abgelaufener Token
Eingang: Exp: 1609459200 (01.01.2021), überprüft am 28.08.2026
Ausgabe: Token is expired —current time (1767225600) > exp (1609459200). Reject and prompt re-login.
Häufige Probleme
- Dekodierung als Verifizierung behandeln: Jeder kann ein JWT mit beliebigen Ansprüchen und einer gefälschten Unterschrift erstellen. Die Dekodierung liest die Nutzlast, beweist aber nichts. Überprüfen Sie die Signatur immer mit dem geheimen/öffentlichen Schlüssel auf dem Server, bevor Sie Ansprüchen vertrauen.
- Verwendung des Algorithmus „none“: Die JWT-Spezifikation erlaubt alg: none für ungesicherte Token. Wenn Ihr Prüfer alg:none akzeptiert, kann ein Angreifer Token fälschen. Konfigurieren Sie Ihre Bibliothek so, dass keine erwarteten Algorithmen abgelehnt und auf die Whitelist gesetzt werden.
- Speichern von JWTs in localStorage: XSS kann localStorage lesen und Token herausfiltern. Bevorzugen Sie httpOnly-, Secure- und SameSite=Strict-Cookies für Sitzungstoken oder kurzlebige In-Memory-Tokens mit einem Refresh-Token-Cookie.
- Exp/aud/iss wird nicht überprüft: Ein gestohlener Token ist gültig, bis er abläuft. Überprüfen Sie bei jeder Anfrage immer exp (Ablauf), aud (beabsichtigte Zielgruppe) und iss (Aussteller), um eine dienstübergreifende Token-Wiedergabe zu verhindern.
Tipps
- Verwenden Sie kurzlebige Zugriffstoken (15 Minuten) sowie langlebige Aktualisierungstoken – dadurch wird das Zeitfenster begrenzt, wenn ein Zugriffstoken gestohlen wird.
- Bevorzugen Sie RS256 (asymmetrisch) gegenüber HS256 (symmetrisch), wenn mehrere Dienste Token überprüfen: Jeder Dienst erhält den öffentlichen Schlüssel und nur der Aussteller verfügt über den privaten Schlüssel.
- Verwenden Sie während der Entwicklung unseren JWT-Decoder, um zu überprüfen, was der Server ausgibt – er zeigt den dekodierten Header, die Nutzlast und eine für Menschen lesbare Anspruchszusammenfassung an, ohne dass das Token irgendwohin gesendet werden muss.
- Fügen Sie niemals sensible Daten (Passwörter, PII) in eine JWT-Nutzlast ein – sie ist Base64-codiert, nicht verschlüsselt und jeder, der das Token abfängt, kann jeden Anspruch lesen.