Transparenz
Methodik
Wie jwtdecoder.de JSON Web Tokens dekodiert, verifiziert und welche RFC-Standards das Tool umsetzt.
Dekodierung - der Standardfall
Jedes JWT besteht aus drei base64url-encodeten Teilen, getrennt durch Punkte. Der Decoder zerlegt den String an den Punkten, dekodiert jeden Teil mit base64url (RFC 4648 §5) und parst Header und Payload als JSON.
Wichtig: base64url ≠ klassisches base64. base64url verwendet - und _ statt + und /, und lässt das Padding (=) weg. Der Decoder rekonstruiert das Padding intern, bevor er an die Browser-API atob gibt.
Signaturprüfung via Web Crypto API
Die Signaturprüfung erfolgt komplett im Browser über die Web Crypto API (W3C-Standard, in allen modernen Browsern verfügbar). Es werden KEINE Daten an einen Server gesendet - weder das Token, noch der Schlüssel.
Unterstützte Algorithmen (nach RFC 7518 JWA):
- HMAC: HS256, HS384, HS512 - Shared Secret
- RSA-PKCS1v1.5: RS256, RS384, RS512 - Public Key (PEM)
- ECDSA: ES256, ES384, ES512 - Public Key (PEM)
ECDSA-Signaturformat-Konvertierung
Ein subtiler Punkt: JOSE (RFC 7518) verlangt ECDSA-Signaturen im raw R||S-Konkatenat-Format (z.B. 64 byte bei ES256). Die Web Crypto API arbeitet ebenfalls mit raw R||S, während OpenSSL und viele Crypto-Libraries ASN.1-DER liefern.
Wenn ein Token mit OpenSSL-Tooling signiert wurde, kann ein Format-Mismatch auftreten. Der Decoder weist in solchen Fällen darauf hin - Konvertierung erfolgt nach RFC 7515 §A.3 (Anhang).
Claims-Validierung
Folgende Claims werden automatisch geprüft, falls sie im Payload vorhanden sind:
| Claim | Prüfung |
|---|---|
exp | Token gilt nur wenn now < exp (Clock-Skew-Hinweis bei sehr knappen Werten) |
nbf | Token gilt erst wenn now >= nbf |
iat | Wird nur informativ angezeigt (keine Pflichtprüfung) |
iss, sub, aud, jti | Werden im Claims-Tab als bekannte Standard-Claims hervorgehoben |
Encoder - Tokens selbst signieren
Der Encoder-Tab erlaubt das Bauen eigener Tokens. Workflow: Header und Payload als JSON editieren, Algorithmus wählen, Secret (für HMAC) oder Private Key (für RSA/ECDSA) eingeben - das Token wird live gebaut und kann kopiert werden. Signierung erfolgt ebenfalls über die Web Crypto API.
Was der Decoder NICHT macht
- Keine JWKS-Lookups: das Tool holt keine Public Keys aus externen JWKS-Endpoints. Der Nutzer muss den Public Key manuell als PEM einfügen.
- Keine Issuer-Validierung: iss, aud und ähnliche werden nicht gegen erwartete Werte geprüft (das ist Sache des Verifier-Codes im konkreten System).
- Keine Persistierung: nichts wird gespeichert, nichts wird geloggt, kein Cookie gesetzt (außer Consent-Cookie).
- Kein Server-Upload: alle Daten bleiben im Browser-Memory.
Standards und Referenzen
- RFC 7519 - JSON Web Token (JWT)
- RFC 7515 - JSON Web Signature (JWS)
- RFC 7518 - JSON Web Algorithms (JWA)
- RFC 7517 - JSON Web Key (JWK)
- RFC 8037 - CFRG Elliptic Curve Algorithms (Ed25519/Ed448 für JOSE)
- RFC 4648 - Base16, Base32, Base64 (inkl. base64url §5)
- Web Cryptography API - W3C Recommendation
Limitierungen
- JWE wird aktuell nicht unterstützt: das Tool erkennt verschlüsselte Tokens (5-teilig statt 3-teilig), kann sie aber nicht entschlüsseln.
- EdDSA: Web Crypto API hat Ed25519-Support seit Chrome 113 / Firefox 130 / Safari 17 - bei älteren Browsern fällt die Verifikation auf "nicht unterstützt".
- PEM-Format-Parsing: der Decoder akzeptiert Standard-PEM (BEGIN PUBLIC KEY / END PUBLIC KEY). PKCS#1-only-Format kann an manchen Stellen Probleme machen - der Decoder zeigt in solchen Fällen einen Hinweis.