Ein JSON Web Token (JWT, RFC 7519) ist ein kompaktes, URL-sicheres Format für die Übertragung signierter und gegebenenfalls verschlüsselter Claims zwischen zwei Parteien. Ein JWT besteht aus drei Base64URL-kodierten Teilen, getrennt durch Punkte: einem Header (Algorithmus, Token-Typ), einem Payload (die eigentlichen Claims, etwa Issuer, Subject, Audience, Expiration, Custom Claims) und einer Signatur (oder einem MAC-Wert). Signiert werden JWTs typischerweise mit RSA, ECDSA oder EdDSA (asymmetrisch) bzw. HMAC mit SHA-2 (symmetrisch); die zugehörigen Standards sind JWS (RFC 7515) für Signaturen und JWE (RFC 7516) für Verschlüsselung.
Eingesetzt werden JWTs in OAuth 2.0 und OpenID Connect als Access Tokens und ID Tokens, in API-Authentifizierung als Bearer Tokens, in zustandslosen Web-Sessions, in mTLS-Pfaden bei mobilen Apps sowie in zahlreichen herstellerspezifischen Authentifizierungs-Schemes. Bekannte Bibliotheken sind Microsoft.IdentityModel.Tokens (.NET), Auth0/jose, jjwt (Java), node-jsonwebtoken, jose-py, golang-jwt sowie viele framework-spezifische Implementierungen.
Der Einsatzzweck liegt in der zustandslosen Übertragung verifizierbarer Aussagen. Klassische Session-Cookies setzen einen serverseitigen Session-Speicher voraus; in horizontal skalierten Microservice-Architekturen führt das zu zentralisierter Last und Konsistenzproblemen. Mit signierten JWTs kann jeder Resource Server die Identität und Rechte des Anrufers selbständig prüfen, ohne den Authorization Server konsultieren zu müssen — solange er den öffentlichen Schlüssel des Issuers kennt (typischerweise über JWKS-Endpunkte).
Historisch wurde JWT von Mike Jones, John Bradley und Nat Sakimura im Rahmen der OAuth- und OIDC-Standardisierung entwickelt; RFC 7519 wurde 2015 veröffentlicht. Die Spezifikation ist Teil einer Familie von Standards rund um JOSE (JSON Object Signing and Encryption). JWT hat sich seitdem zur dominanten Token-Form für API-Authentifizierung entwickelt, ist aber wiederholt kritisiert worden — insbesondere von Forschern wie Paragon Initiative — wegen Schwächen wie der "alg: none"-Sicherheitslücke, Algorithmus-Verwirrung und der unsachgemäßen Nutzung als Session-Token mit langer Lebensdauer.
Die berüchtigte "alg: none"-Schwachstelle früher JWT-Bibliotheken erlaubte Angreifern, das Signaturverfahren auf "keine Signatur" zu setzen, sodass Bibliotheken die Signaturprüfung übersprangen. Diese Schwachstelle ist mehrfach in Bibliotheken aufgetreten und hat über Jahre als pädagogisches Beispiel gedient — sowohl für die Wichtigkeit, eine Allowlist erlaubter Algorithmen zu verwenden, als auch für die Tücke vermeintlich harmloser Defaults. Heute schließen seriöse JWT-Bibliotheken "alg: none" standardmäßig aus, das Beispiel bleibt aber ein Standardlehrstück in Application-Security-Trainings.