TK TaskKit
Developer-Tools

JWT-Decoder

JWTs decodieren, Claims inspizieren und Ablauf prüfen, ohne den Token hochzuladen.

DecodierenEncodieren
Token
Decodiert

Füge einen JWT ein, um Header, Payload und Standard-Claims zu prüfen.

HS256-Token, signiert mit dem Geheimnis „taskkit-demo-secret" — wechsle in den Verify-Modus und füge das Geheimnis ein, um die Verifizierung zu testen.

Eingaben bleiben auf diesem Gerät. Alle Developer-Tools auf TaskKit laufen vollständig im Browser. Tokens, Payloads und eingefügte Texte werden weder an TaskKit noch an Dritte übertragen.

Was dieses Tool macht

Dieser JWT-Decoder zerlegt einen JSON Web Token in seine drei Teile — Header, Payload und Signatur — und zeigt den decodierten Inhalt zusammen mit den Standard-Claims (iss, sub, aud, exp, iat, nbf, jti). Das Gültigkeitsfenster wird aus exp und nbf berechnet, sodass du auf einen Blick siehst, ob ein Token aktuell gültig ist.

Zusätzlich gibt es Signatur-Verifizierung für die Algorithmen, die APIs in der Praxis tatsächlich nutzen: HS256/384/512 mit gemeinsamem Geheimnis, RS256/384/512 und PS256/384/512 mit RSA-Public-Key, ES256/384/512 mit EC-Public-Key sowie EdDSA mit Ed25519. Public Keys können als JWK, vollständiges JWKS (TaskKit wählt automatisch den passenden Key über das kid aus dem Token-Header), PEM-SPKI-Block, PEM-PKCS#1-RSA-Public-Key, X.509-Zertifikat (der Public Key wird automatisch extrahiert) oder — für EdDSA — als 64 Hex-Zeichen oder 43 base64url-Zeichen eingefügt werden. Enthält der Token-Header einen x5c-Array (eingebettete X.509-Zertifikatskette), wird das Leaf-Zertifikat automatisch verwendet, sofern das Schlüsselfeld leer ist.

Wann du es brauchst

  • Inspizieren eines Tokens vom Auth-Server während der lokalen Entwicklung.
  • Prüfen, ob die Claims eines Drittanbieter-Tokens den Erwartungen des Clients entsprechen.
  • Verifizieren, dass ein erneuerter Token mit demselben Schlüssel signiert wurde.
  • Überprüfen der Ablaufzeit, wenn etwas exakt um Mitternacht UTC aufgehört hat zu funktionieren.

Wie es funktioniert

Die Decodierung ist reines Base64URL — die JWT-Spezifikation nutzt URL-safes Base64 ohne Padding. Header und Payload sind JSON; die Signatur sind Rohbytes. Die Verifizierung läuft über crypto.subtle.verify, die in den Browser eingebaute WebCrypto-API. EdDSA nutzt @noble/ed25519 (ebenfalls reine Browser-Bibliothek), da WebCryptos Ed25519-Unterstützung browserübergreifend noch lückenhaft ist.

Die Schlüssel-Eingabe ist großzügig im Format. Symmetrische Schlüssel (HS*) werden als Rohbytes oder JWK importiert. Asymmetrische (RS/PS/ES) akzeptieren JWK, JWKS (das kid im Token-Header wählt den richtigen Key — bei Einzelkey-Sets wird er direkt genommen), PEM-SPKI (BEGIN PUBLIC KEY), PEM-PKCS#1-RSA-Public-Key (BEGIN RSA PUBLIC KEY) oder ein X.509-Zertifikat (BEGIN CERTIFICATE) — TaskKit liest das Zertifikat mit einem kleinen eingebauten ASN.1-Reader und extrahiert die SubjectPublicKeyInfo. EdDSA-Schlüssel können JWK, JWKS, SPKI-PEM, 64 Hex-Zeichen oder 43 base64url-Zeichen sein.

Nichts an diesem Tool läuft serverseitig. Der Token verlässt den Browser nicht, der Schlüssel verlässt den Browser nicht, und es gibt keine Telemetrie auf beidem. Wenn du einen Produktions-Token zum Debuggen einfügst, sieht dein Auditor keinen Request an taskkit.net, der diesen Token enthält.

Hinweise

Warum wird alg: none abgelehnt, auch wenn der Token sonst valide ist? Weil kein realer JWT jemals alg: none verwenden sollte. Es ist ein bekannter Angriffsvektor: Akzeptiert dein Verifier none, kann ein Angreifer die Signatur entfernen und beliebige Payloads fälschen. Wir melden es als Fehler statt es stillschweigend durchzulassen.

Kann ich einen Microsoft-/Google-/Auth0-Token verifizieren? Ja — lade das JWKS des Issuers (z. B. https://login.microsoftonline.com/common/discovery/v2.0/keys) und füge das gesamte JSON-Dokument ins Schlüsselfeld ein. TaskKit liest das kid aus dem Token-Header und wählt den passenden JWK automatisch — kein manuelles Suchen nötig.

HS256 vs. RS256 — welcher? RS256 (oder ES256) für alles, was Externe verifizieren sollen — sie brauchen nur den Public Key. HS256 ist okay zwischen Services, wenn beide Seiten dasselbe Geheimnis halten.

Mein Token hat einen x5c-Header — bedeutet das, dass ich dem eingebetteten Zertifikat vertraue? TaskKit nutzt das Leaf-Zertifikat aus x5c, um die Signatur zu verifizieren, wenn du keinen Schlüssel einfügst — so kannst du bestätigen, dass der Token-Inhalt nicht manipuliert wurde. Die Kette wird nicht bis zu einem CA-Root validiert; das erfordert Trust Roots und ist hier nicht im Scope. Das Ergebnis zeigt "mit dem x5c-Zertifikat aus dem Token-Header verifiziert (Kette nicht geprüft)" — damit du es nicht mit einer End-to-End-Vertrauensaussage verwechselst.

Verwandte Tools