JWT- und JWS-Tokens im Browser dekodieren

Die drei Teile verstehen

Ein signiertes JWT besteht gewöhnlich aus drei durch Punkte getrennten Teilen: Base64URL-Header, Base64URL-Nutzdaten und Signatur. JWS beschreibt die signierte Hülle. Die ersten beiden Teile sind kodiert, nicht verschlüsselt. Besitzer des Tokens können sie normalerweise lesen. Verschlüsselte Tokens haben gegebenenfalls ein anderes Format, das dieser Decoder nicht unterstützt.

Ein Token untersuchen

Öffnen Sie den JWT-Decoder, fügen Sie ein Beispieltoken ein und prüfen Sie das JSON. Der Decoder verarbeitet die Daten lokal im Browser. Ungültiges Base64URL oder fehlerhaftes JSON sind Eingabefehler und kein Beweis für einen Angriff. Geben Sie nur das Token ein, ohne HTTP-Authorization-Header.

{ "alg": "HS256", "typ": "JWT" }

Claims richtig einordnen

alg nennt den angegebenen Signaturalgorithmus. iss bezeichnet den Aussteller und aud die Zielgruppe; exp, nbf und iat sind Unix-Zeitstempel in Sekunden. Der Zeitstempel-Konverter hilft beim Lesen der Daten. Prüfen Sie diese Werte serverseitig mit vertrauenswürdigen Schlüsseln und einer ausdrücklichen Algorithmusliste. Dekodierte Claims allein dürfen keine Zugriffsentscheidung begründen.

Vertrauliche Eingaben schützen

Der Kern-Decoder arbeitet lokal. Optionale KI-Hilfe ist ein eigener Vorgang und kann Eingaben nach Zustimmung an einen externen Anbieter senden. Verwenden Sie keine echten Zugangsdaten. Beim Laden der Website entstehen normale Ressourcenanfragen. Offline-Nutzung setzt erfolgreich zwischengespeicherte Seiten und Dateien voraus. Das Leeren des Eingabefelds garantiert keine sichere Speicherlöschung.

Typische Fallstricke bei der Validierung (RFC 7519)

Bei der Fehlerbehebung von JWT-Tokens in Produktionsumgebungen ist die reine Nutzdatenanalyse nur der erste Schritt. Entwickler müssen drei wesentliche Sicherheitsgrenzen beachten:

1. Die “none”-Algorithmus-Schwachstelle: Veraltete Bibliotheken akzeptieren unter Umständen Tokens mit "alg": "none", wodurch die Signaturprüfung umgangen wird. Erzwingen Sie stets eine strenge Positivliste zulässiger Algorithmen (z. B. ausschließlich RS256 oder ES256).
2. Schlüsselverwechslungsangriffe (HMAC vs. RSA): Erwartet das Backend einen öffentlichen RSA-Schlüssel, prüft ihn jedoch unsicher, kann ein Angreifer ein gefälschtes Token mit HMAC-SHA256 signieren und den öffentlichen Schlüssel als Geheimnis missbrauchen. Der Token-Header darf die kryptografische Familie niemals dynamisch bestimmen.
3. Uhrzeitabweichungen und Latenz: Zeitstempelprüfungen (exp, nbf) schlagen häufig durch minimale Zeitunterschiede zwischen Serverknoten fehl. Richten Sie in Ihrer Verifizierungslogik ein Zeitfenster (Toleranz von 30 bis 60 Sekunden) für NTP-Abweichungen ein.