Wichtige Fakten
- Kategorie
- Sicherheit & Validierung
- Eingabetypen
- textarea, select, text, number
- Ausgabetyp
- html
- Sample-Abdeckung
- 4
- API verfügbar
- Yes
Überblick
Der JWT Inspector & Verifier ermöglicht das schnelle Dekodieren und Überprüfen von JSON Web Tokens (JWT). Das Tool entschlüsselt Header und Payload in lesbares JSON, analysiert Standard-Claims wie Ablaufzeit oder Gültigkeit und verifiziert die kryptografische Signatur mithilfe von Shared Secrets (HS*) oder asymmetrischen öffentlichen Schlüsseln (RS*, PS*, ES*, EdDSA).
Wann verwenden
- •Wenn Sie den Inhalt eines verschlüsselten oder kodierten JSON Web Tokens schnell im Klartext analysieren möchten.
- •Wenn Sie die Gültigkeit von Standard-Claims wie Ablaufzeit (exp) oder Aussteller (iss) prüfen und eventuelle Zeitabweichungen diagnostizieren müssen.
- •Wenn Sie die kryptografische Signatur eines Tokens mit einem Shared Secret oder einem öffentlichen Schlüssel (PEM/JWK) verifizieren wollen.
So funktioniert es
- •Fügen Sie das kompakte JWT-Token in das Eingabefeld ein.
- •Wählen Sie den Verifizierungsmodus (nur dekodieren, Signatur prüfen oder Fälschungs-Demo) und geben Sie optional das Shared Secret oder den Public-Key (PEM/JWK) an.
- •Das Tool dekodiert Header und Payload mittels Base64url und führt eine serverseitige Signaturprüfung mit Node-Crypto durch.
- •Sie erhalten eine strukturierte HTML-Ausgabe mit farblich hervorgehobenem JSON, einer Diagnose der Standard-Claims und dem Verifizierungsstatus.
Anwendungsfälle
Beispiele
1. HS256-Token verifizieren
Backend-Entwickler- Hintergrund
- Ein Entwickler möchte prüfen, ob das von einer API generierte JWT-Token mit dem korrekten Shared Secret signiert wurde und ob die Claims gültig sind.
- Problem
- Manuelles Dekodieren und Berechnen der HMAC-SHA256-Signatur ist fehleranfällig.
- Verwendung
- Fügen Sie das JWT-Token ein, wählen Sie den Modus 'Signatur prüfen' und tragen Sie das Shared Secret in das entsprechende Feld ein.
- Beispielkonfiguration
-
token: 'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkphbmUgRG9lZSIsImlhdCI6MTUxNjIzOTAyMn0.yo-bLjjeUhUPia17JiJbc2f1e0JXJIJAi4auivcB-IY', mode: 'verify', secret: 'demo-secret-2026' - Ergebnis
- Das Tool zeigt den dekodierten Payload im Klartext an und bestätigt die erfolgreiche Verifizierung der Signatur.
2. RS256-Token mit Public-Key prüfen
Security-Auditor- Hintergrund
- Ein Auditor muss ein von einem Identity Provider ausgestelltes Token validieren, das asymmetrisch signiert wurde.
- Problem
- Die Signatur muss gegen einen öffentlichen RSA-Schlüssel im PEM-Format geprüft werden.
- Verwendung
- Fügen Sie das Token ein, wählen Sie 'Signatur prüfen' und fügen Sie den öffentlichen Schlüssel (BEGIN PUBLIC KEY) in das Feld 'Public-Key PEM / JWK' ein.
- Beispielkonfiguration
-
token: 'eyJhbGciOiJSUzI1NiIs...', mode: 'verify', publicKey: '-----BEGIN PUBLIC KEY-----\nMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...' - Ergebnis
- Die Signatur wird erfolgreich gegen den öffentlichen Schlüssel validiert und abgelaufene Claims werden rot markiert.
Mit Samples testen
jsonVerwandte Hubs
FAQ
Werden meine eingegebenen Schlüssel oder Secrets auf dem Server gespeichert?
Nein. Die Verifizierung erfolgt zwar serverseitig über Node-Crypto, aber die Secrets und Schlüssel werden nur für die aktuelle Anfrage verwendet und nicht dauerhaft gespeichert.
Welche Signatur-Algorithmen werden vom Verifier unterstützt?
Das Tool unterstützt symmetrische Algorithmen (HS256, HS384, HS512) sowie asymmetrische Verfahren (RS*, PS*, ES*, EdDSA) mittels PEM- oder JWK-Schlüsseln.
Was passiert, wenn ein Token den Algorithmus 'none' verwendet?
Tokens mit 'alg=none' werden vom Tool zwar dekodiert, aber aus Sicherheitsgründen niemals als gültig verifiziert.
Wie kann ich eine minimale Zeitabweichung bei der Ablaufprüfung berücksichtigen?
Sie können im Feld 'Erlaubte Abweichung' (Clock Skew) eine Toleranzzeit in Sekunden angeben, um kleine Server-Zeitunterschiede auszugleichen.
Was zeigt die Fälschungs-Demo (Forge-Modus)?
Sie demonstriert, wie ein manipulierter Payload mit dem angegebenen Schlüssel neu signiert wird, um zu verdeutlichen, warum Backend-Systeme den erwarteten Algorithmus fest vorgeben müssen.