Kostenloser JWT-Decoder

Eine kurze Geschichte der JSON Web Tokens

Der JSON Web Token (JWT) wurde im Mai 2015 als RFC 7519 von Michael B. Jones (Microsoft), John Bradley (Ping Identity) und Nat Sakimura (NRI) unter der IETF-JOSE Working Group standardisiert. Es war der Höhepunkt eines halben Jahrzehnts Arbeit: Der erste JWT-Internet-Draft erschien im Dezember 2010 und entstand aus dem schwergewichtigen XML-basierten Assertion-Format von SAML 2.0 (2005) und dem gefühlten Bedarf nach etwas Leichterem, das Browser nativ parsen konnten. Der Durchbruch war die Wahl von JSON statt XML und base64url statt PEM: Ein JWT passte in eine URL-Query-String oder einen Authorization: Bearer-Header. Die gesamte JOSE-Familie wurde als koordinierter Satz ausgeliefert: RFC 7515 (JWS) zum Signieren, RFC 7516 (JWE) zum Verschlüsseln, RFC 7517 (JWK) für das Schlüsselformat, RFC 7518 (JWA) für Algorithmus-Kennungen und RFC 7519 (JWT) für die Claims-Schicht, alle am selben Tag im Mai 2015. Die Annahme war sofort. OAuth 2.0 (RFC 6749, 2012) hatte Access-Tokens standardisiert, aber ihr Format offen gelassen; die Industrie wählte JWT. OpenID Connect (Dezember 2014, OpenID Foundation) machte JWT für ID-Tokens verpflichtend. Bis 2017 stellte jeder große Identitätsanbieter (Auth0, Okta, Azure AD, AWS Cognito, Google Identity, Firebase Auth) JWTs als sein natives Session-Format aus. JWT.io, die Decoder-Website, die Auth0 2014 startete, wurde zum De-facto-Tool für JWT-Debugging und half, die Entwickler-Aufmerksamkeit für das Format zu zementieren. Zwei Sicherheitsvorfälle prägten das moderne Bedrohungsmodell: Tim McLeans Offenlegung von 2015 des alg: none-Bypasses und des HS/RS-Algorithmus-Verwechslungsangriffs sowie CVE-2022-21449 (April 2022), der von Neil Madden gefundene «Psychic Signatures»-Bug im ECDSA-Verifier von Java 15-18. Beide führten zur Standard-Härtung von Bibliotheken: Die meisten modernen Bibliotheken lehnen jetzt alg: none rundheraus ab und fixieren den erwarteten Algorithmus, statt ihn aus dem Token-Header zu lesen.

Die Anatomie eines JWT

• Drei base64url-kodierte Segmente. Ein JWT ist die Zeichenkette header.payload.signature: drei durch Punkte getrennte Segmente, jedes base64url-kodiert. RFC 7519 nennt das die JWT Compact Serialization. Das Ganze passt in eine URL oder einen HTTP-Header; diese Kompaktheit war das Designziel, das JWT von XML-basierten Vorgängern wie SAML unterschied.
• Header. Ein kleines JSON-Objekt, das normalerweise zwei Felder enthält: alg (der Signaturalgorithmus, z. B. HS256, RS256, ES256) und typ (fast immer «JWT»). Optionale Felder umfassen kid (eine Schlüsselkennung für die Schlüsselrotation) und cty (Inhaltstyp für verschachtelte Tokens). Der Header sagt dem Verifier, wie die Signatur zu validieren ist; vertraue ihm nie allein, fixiere immer den erwarteten Algorithmus serverseitig.
• Payload. Ein JSON-Objekt von Claims, Schlüssel-Wert-Behauptungen über ein Subjekt. RFC 7519 §4.1 reserviert sieben Standard-Claims: iss (Issuer), sub (Subject), aud (Audience), exp (Expiration), nbf (Not Before), iat (Issued At) und jti (eindeutige JWT-ID). Issuer fügen frei eigene Claims hinzu. Die Payload ist signiert, aber nicht verschlüsselt: Jeder mit dem Token kann sie lesen.
• Signatur. Der kryptographische Beweis, dass Header und Payload nicht manipuliert wurden. Die Signatur-Eingabe ist die literale Zeichenkette base64url(header) + "." + base64url(payload); die Signatur selbst wird dann als drittes Segment base64url-kodiert. Verifizierung erfordert das symmetrische Geheimnis (HS*) oder den asymmetrischen öffentlichen Schlüssel (RS*, ES*, PS*, EdDSA) und muss immer auf einem vertrauenswürdigen Server geschehen.
• base64url, nicht base64. JWT-Segmente verwenden die URL-sichere base64-Variante aus RFC 4648 §5: Zeichen 62 ist - statt +, Zeichen 63 ist _ statt /, und das abschließende =-Padding wird entfernt. JavaScripts eingebautes atob() handhabt nur Standard-base64, daher übersetzen JWT-Decoder das Alphabet und füllen vor dem Decodieren wieder auf.
• NumericDate: Sekunden, keine Millisekunden. RFC 7519 definiert exp, nbf und iat als «die Anzahl der Sekunden seit 1970-01-01T00:00:00Z UTC». JavaScripts Date.now() gibt Millisekunden zurück, daher ist ein häufiger Bug ein exp, der drei Größenordnungen zu groß ist und einen Token erzeugt, der «im Jahr 53.000 abläuft». Verwende beim Ausstellen von Tokens immer Math.floor(Date.now() / 1000).

Wo JWTs in der Praxis verwendet werden

• OAuth-2.0-Access-Tokens. RFC 6749 ließ das Access-Token-Format offen, aber in der Praxis standardisierte sich die Industrie auf JWT. Auth0, Okta, Azure AD, AWS Cognito und Google Identity stellen alle standardmäßig JWT-Access-Tokens aus. Das Bearer-Token in deinem Authorization-Header ist fast immer ein JWT.
• OpenID-Connect-ID-Tokens. OIDC (Dezember 2014) verlangt JWT für seinen id_token. Der id_token trägt Identitäts-Claims über den authentifizierten Benutzer (sub, email, name, picture) und wird von der vertrauenden Partei konsumiert, statt weitergegeben. Dies ist der primäre Mechanismus hinter «Mit Google anmelden», «Mit Apple anmelden» und entsprechenden Flows.
• API-Authentifizierung. Zustandslose REST-APIs nutzen JWT, weil es die Notwendigkeit eines serverseitigen Session-Stores entfernt: Die API vertraut dem, was die Signatur verifiziert. Stripe-artige API-Schlüssel bleiben für Server-zu-Server-Verkehr üblich, aber für benutzerbezogene APIs ist das Muster Authorization: Bearer <jwt> nun Standard.
• Microservice-zu-Microservice-Auth. Ein benutzerbezogenes, am API-Rand ausgestelltes JWT wird durch interne Service-zu-Service-Aufrufe weitergeleitet und lässt jeden Service der ursprünglichen Authentifizierung vertrauen, ohne erneut zu authentifizieren. Das Muster wird manchmal «Token-Translation» genannt: Das Edge-Gateway tauscht eine opake Session gegen ein kurzlebiges JWT mit Scope auf den nachgelagerten Aufruf.
• Single-Page-Application-Sessions. SPAs (React, Vue, Angular) speicherten historisch Access-Tokens aus Bequemlichkeit in localStorage. Moderne Empfehlungen (OWASP, Auth0) raten dazu, Access-Tokens im Speicher und Refresh-Tokens in HttpOnly + Secure + SameSite=Strict-Cookies zu halten, weil localStorage von jedem XSS lesbar ist, das auf der Seite landet.
• Mobile-App-Sessions. iOS- und Android-Apps speichern Access-Tokens im Plattform-Keychain oder Keystore. Das Token wird bei jedem Backend-Aufruf als Authorization: Bearer gesendet. Refresh-Tokens werden bei jeder Nutzung rotiert, und das kurze exp des Access-Tokens (typischerweise 5-15 Minuten) ist die primäre Verteidigung gegen Replay bei gestohlenem Gerät.

Standards und Sicherheits-Meilensteine

• RFC 7519 (JWT, Mai 2015). Die Basisspezifikation. Definiert die JWT Compact Serialization, die sieben standardmäßig registrierten Claims (iss, sub, aud, exp, nbf, iat, jti) und das NumericDate-Format. Autoren: Michael B. Jones, John Bradley, Nat Sakimura.
• RFC 7515 (JWS, Mai 2015). JSON Web Signature. Das signierte Wrapper-Format, das fast jeder umgangssprachlich «JWT» nennt: drei base64url-Segmente, durch Punkte verbunden. JWS unterstützt sowohl die kompakte als auch die JSON-Serialization-Form; JWT verwendet nur die kompakte Form.
• RFC 7516 (JWE, Mai 2015). JSON Web Encryption. Die verschlüsselte Variante mit fünf Segmenten (Header, verschlüsselter Schlüssel, IV, Ciphertext, Authentifizierungs-Tag). Verwende JWE, nicht JWS, wenn die Payload vertraulich sein muss, nicht nur manipulationssicher.
• RFC 7517 (JWK, Mai 2015). JSON Web Key. Die JSON-Darstellung kryptographischer Schlüssel. Der JWKS-Endpunkt (/.well-known/jwks.json) veröffentlicht ein JSON Web Key Set, den modernen Mechanismus für ausfallzeitfreie Schlüsselrotation: Verifier suchen Schlüssel nach kid.
• RFC 7518 (JWA, Mai 2015). JSON Web Algorithms. Das Register der alg-Kennungen: HS256/384/512 (HMAC), RS256/384/512 (RSASSA-PKCS1-v1_5), ES256/384/512 (ECDSA), PS256/384/512 (RSASSA-PSS), EdDSA (Ed25519/Ed448) und das (absichtlich selten verwendete) none.
• Der alg: none-Bypass (Tim McLean, 2015). RFC 7518 listet none als gültigen Algorithmuswert für ungesicherte Kontexte. Naive Verifier akzeptierten ein Token mit zu {"alg":"none"} umgeschriebenem Header und leerer Signatur, sodass Angreifer beliebige Payloads fälschen konnten. Moderne Bibliotheken lehnen none standardmäßig ab; die Spezifikation selbst besagt, dass Verifier «standardmäßig KEINE ungesicherten JWSs akzeptieren DÜRFEN».
• HS/RS-Algorithmus-Verwechslungsangriff (Tim McLean, 2015). Wenn ein Verifier den Algorithmus aus dem Token-Header wählt, statt ihn zu fixieren, kann ein Angreifer den Header zu HS256 umschreiben und das Token mit dem öffentlichen RSA-Schlüssel des Servers als HMAC-Geheimnis signieren. Die Bibliothek sieht HS256, behandelt den konfigurierten öffentlichen RSA-Schlüssel als symmetrisches Geheimnis, und die Signatur ist gültig. Mitigation: Fixiere den erwarteten Algorithmus außerhalb der Übertragung; leite ihn nie aus dem Token ab.
• CVE-2022-21449 «Psychic Signatures» (Neil Madden, April 2022). Der ECDSA-Verifier von Java 15-18 prüfte nicht, dass die r- und s-Werte der Signatur ungleich null waren, was bedeutete, dass eine buchstäblich aus Nullen bestehende Signatur als gültig akzeptiert wurde. Mit ES256/384/512 auf betroffenen JVMs signierte JWTs konnten mit leerer Signatur gefälscht werden. Im Critical Patch Update von Oracle im April 2022 behoben.

Weitere häufig gestellte Fragen

Verwandte Werkzeuge