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).
Aufbau des Tokens
Ein JWT besteht aus drei durch Punkte getrennten Teilen: header.payload.signature. Header und Payload sind Base64URL-kodiert; dieses Werkzeug dekodiert sie in lesbares JSON.
Grundlegende Nutzung
Füge ein JWT-Token ein (drei durch Punkte getrennte Teile), um den Header, den dekodierten Payload und die Metadaten (Ablauf, iat usw.) zu sehen.
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.
Verifizieren
Im Tab Verifizieren prüfst du die Signatur wirklich (HS/RS/ES/PS), indem du das Geheimnis (HMAC) oder den öffentlichen Schlüssel (PEM oder JWK) angibst. alg:none wird abgelehnt und auf Algorithmus-Verwechslung hingewiesen. Alles geschieht in deinem Browser: Der Schlüssel verlässt niemals dein Gerät.
Erstellen und testen
Unter Erstellen baust du ein JWT aus Feldern zusammen und signierst es (HMAC-Geheimnis oder ein Schlüsselpaar, das du generieren kannst). Unter Authz testen definierst du Gateway-Regeln (Issuer, Audience, Scopes/Rollen) und siehst, ob das Token ALLOW oder DENY ergäbe.
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.
Signatur und Sicherheit
Die Signatur garantiert, dass der Token nicht manipuliert wurde, aber der Inhalt wird nicht verschlüsselt: Jeder kann den Payload lesen. Nimm niemals sensible Daten ohne zusätzliche Verschlüsselung (JWE) auf.
