Dekodieren
Verifizieren
Erstellen
Authz testen
Bedienungsanleitung
Was ein JWT ist
Ein JWT (JSON Web Token) ist eine kompakte, signierte Berechtigung, die als Textzeichenkette übertragen wird. Es wird vor allem als Zugriffstoken bei APIs, Logins und OAuth 2.0 / OpenID Connect verwendet: der Client sendet es bei jeder Anfrage im Header Authorization: Bearer … und der Server prüft die Signatur, um zu wissen, wer du bist und was du tun darfst — ohne eine Datenbank abzufragen. Die Signatur garantiert, dass niemand es manipuliert hat, verschlüsselt aber nicht seinen Inhalt: jeder kann ihn lesen (genau das macht dieses Tool).
Die drei Teile
Ein JWT hat drei durch Punkte getrennte Teile: header.payload.signature.
• Header (Kopfteil) — JSON mit dem Signaturalgorithmus (alg) und dem Typ (typ: JWT); manchmal ein kid, der den verwendeten Schlüssel identifiziert.
• Payload (Nutzlast) — JSON mit den Claims: den Daten des Tokens (Nutzer, Berechtigungen, Ablauf…).
• Signature (Signatur) — das Ergebnis der Signierung von header.payload mit dem Algorithmus aus dem Header.
Header und Payload sind Base64URL-kodiert (das ist keine Verschlüsselung, nur URL-sicherer Text). Dieses Tool dekodiert sie in lesbares JSON und färbt die drei Teile ein.
Verwendung
Zwei Arbeitsweisen:
• Dekodieren — füge ein Token im Tab Dekodieren ein, und du siehst sofort den Header, den Payload und eine Tabelle der Claims mit ihrer Bedeutung und ihrem Ablauf. Zum Lesen brauchst du den Schlüssel nicht.
• Erstellen — im Tab Erstellen schreibst du den Payload (JSON), wählst den Algorithmus, gibst das Geheimnis oder den privaten Schlüssel an und erhältst ein signiertes Token.
Das gerade erstellte Token bringst du mit einem Klick zu Verifizieren oder zum Authentifizierungsfluss-Visualisierer. Alles geschieht in deinem Browser: Weder Tokens noch Schlüssel verlassen dein Gerät.
Signaturalgorithmen (einzeln erklärt)
Das Feld alg im Header gibt an, mit welchem Algorithmus signiert wurde. Dieses Tool unterstützt 12, in drei Familien; die Zahl ist die Größe des SHA-Hashs (256/384/512).
• HS256 / HS384 / HS512 (HMAC + SHA) — symmetrisch: derselbe geheime Schlüssel signiert und verifiziert. Einfach und schnell. Verwende sie, wenn Signierender und Prüfender dieselbe Partei sind oder das Geheimnis sicher teilen (z. B. ein Backend, das eigene Tokens ausstellt und konsumiert). Nachteil: wer verifizieren kann, kann auch fälschen.
• RS256 / RS384 / RS512 (RSA PKCS#1 v1.5 + SHA) — asymmetrisch: signiert wird mit dem privaten Schlüssel, verifiziert mit dem öffentlichen Schlüssel. Am weitesten verbreitet in OAuth/OIDC: der Aussteller behält den privaten und veröffentlicht den öffentlichen Schlüssel (JWKS), damit jeder verifizieren kann, ohne fälschen zu können. Große Schlüssel (2048 Bit) und langsamere Signatur.
• PS256 / PS384 / PS512 (RSA-PSS + SHA) — asymmetrisches RSA wie RS, aber mit PSS-Padding (probabilistisch), gilt als robuster. Wähle es, wenn deine Plattform es unterstützt und du das moderne RSA willst.
• ES256 / ES384 / ES512 (ECDSA + Kurven P-256/P-384/P-521) — asymmetrisch mit elliptischen Kurven: gleiche Garantien wie RSA, aber mit viel kleineren und schnelleren Schlüsseln und Signaturen. Gute Standardwahl für neue Tokens.
Faustregel: HS*, wenn du ein Geheimnis in einer kontrollierten Umgebung teilst; ES* oder RS*/PS*, wenn Dritte verifizieren müssen, ohne ausstellen zu können.
Die Signatur verifizieren
In Verifizieren wird die Signatur wirklich geprüft (Web-Crypto-Kryptografie des Browsers):
• Wähle den Algorithmus (der im Header angegebene ist vorausgewählt).
• Bei HS* füge das Geheimnis ein. Bei RS/PS/ES* füge den öffentlichen Schlüssel im PEM-Format (-----BEGIN PUBLIC KEY-----) oder als JWK (JSON) ein; das Tool erkennt, um welches es sich handelt.
• Du siehst Signatur gültig oder ungültig, dazu die Prüfungen auf Ablauf (exp) und „noch nicht gültig“ (nbf).
Zwei zentrale Schutzmaßnahmen: alg:none (unsignierte Tokens) wird immer abgelehnt, und du wirst vor Algorithmus-Verwechslung gewarnt — ein asymmetrisches Token als HMAC zu verifizieren (oder umgekehrt) ist eine bekannte Sicherheitslücke. Der Schlüssel verlässt niemals dein Gerät.
Erstellen und signieren
In Erstellen baust du ein Token und signierst es:
• Schreibe den Payload als JSON; mit den Chips fügst du schnell registrierte Claims (sub, iss, aud, exp…) oder gängige (name, role, scope…) mit Beispielwerten hinzu.
• Wähle den Algorithmus und gib das Geheimnis (HS*) oder den privaten Schlüssel als PEM/JWK an (RS/PS/ES*). Optional: ein kid im Header.
• Schlüssel erzeugen erstellt sofort ein zufälliges Geheimnis (HMAC) oder ein Schlüsselpaar (privat + öffentlich in PEM und JWK) zum Testen.
• Signiere und kopiere das Token. Mit einem Klick bringst du es zu Verifizieren (Round-Trip) oder zum Authentifizierungsfluss.
Standard-Claims und Ablauf
Die Claims sind die Felder der Payload. Die registrierten (RFC 7519) haben eine Standardbedeutung:
• iss — Aussteller: wer das Token erstellt hat.
• sub — Subjekt: wen es identifiziert (normalerweise den Nutzer).
• aud — Zielgruppe: für wen es bestimmt ist; der Empfänger muss darin enthalten sein.
• exp — Ablauf: der Zeitpunkt, ab dem es ungültig wird.
• nbf — nicht vor: gilt erst ab diesem Zeitpunkt.
• iat — ausgestellt am: wann es erstellt wurde.
• jti — eindeutige ID: nützlich für Widerruf oder Anti-Replay.
Die Zeiten sind in Unix-Sekunden (Sekunden seit 1970). Das Tool zeigt sie als lokales Datum und relativ an („vor 3 Std.“, „in 42 Min.“) und markiert rot, wenn das Token abgelaufen ist (exp in der Vergangenheit) oder noch nicht gültig (nbf in der Zukunft). Achtung: Dekodieren validiert nicht — der Ablauf gilt nur verbindlich, wenn der Server ihn bei der Verifizierung prüft.
Authz testen
Der Tab Authz testen simuliert die Entscheidung eines Gateways oder einer API: du definierst die Regeln, die du verlangen würdest (Aussteller, Zielgruppe, Scopes/Rollen), und das Tool gleicht das eingefügte Token ab und zeigt ALLOW oder DENY Regel für Regel, mit Angabe, was fehlt oder nicht übereinstimmt (einschließlich exp und nbf). So verstehst du, warum ein Token akzeptiert oder abgelehnt würde, ohne das Backend aufzusetzen.
Sicherheit
Die wichtigsten Punkte:
• Die Signatur belegt Integrität und Herkunft, verschlüsselt aber nicht: Der Payload ist für jeden lesbar. Nimm niemals sensible Daten (Passwörter, Kartendaten…) ohne zusätzliche Verschlüsselung (JWE) in ein JWT auf.
• Behandle Tokens wie Geheimnisse: Füge sie nicht in öffentliche Orte ein und speichere sie nicht in Repos. Die Beispiele hier verwenden Spielzeug-Geheimnisse und -Schlüssel; für die Produktion nutze echte, sicher erzeugte Schlüssel und füge sie nicht in dieses Tool ein.
• Setze immer exp (kurzer Ablauf) und prüfe auf dem Server sowohl die Signatur als auch den erwarteten Algorithmus. Lehne alg:none und Algorithmus-Verwechslung ab.
• Die gesamte Arbeit erfolgt lokal in deinem Browser: Nichts wird an irgendeinen Server gesendet.
