JSON Web Token (JWT)
Was ist ein JSON Web Token?
Ein JSON Web Token ist ein kompaktes, URL-sicheres Datenformat, das Aussagen über einen Nutzer oder eine Anwendung zwischen Systemen überträgt. Ein Server signiert das Token kryptografisch, damit der Empfänger Manipulationen erkennt. Der Inhalt ist meist lesbar und daher ohne zusätzliche Verschlüsselung nicht für vertrauliche Daten geeignet.
Ein JSON Web Token, kurz JWT, wird vor allem für die Authentifizierung, Autorisierung und den abgesicherten Datenaustausch zwischen Webanwendungen, Apps, Schnittstellen und Servern eingesetzt. Der Standard ist in RFC 7519 beschrieben. Ein Empfänger kann die enthaltenen Angaben prüfen, ohne dafür bei jeder Anfrage eine zentrale Sitzung aus einer Datenbank laden zu müssen.
Aufbau eines JSON Web Tokens
Ein signiertes JSON Web Token besteht üblicherweise aus drei Abschnitten: Header, Payload und Signatur. Die Abschnitte werden mit Base64url kodiert und durch Punkte getrennt. Base64url macht Binärdaten für URLs und HTTP-Übertragungen geeignet, verschlüsselt den Inhalt aber nicht.
Base64url(Header).Base64url(Payload).Signatur. Zwei Punkte trennen damit drei Segmente. Ein verschlüsseltes Token in der kompakten JWE-Darstellung besitzt dagegen fünf Segmente. Welche Claims enthält ein JWT?
Claims sind Schlüssel-Wert-Paare innerhalb der Payload. Standardisierte Claims erleichtern die Prüfung zwischen verschiedenen Systemen. iss bezeichnet den Aussteller, sub das Subjekt, aud den vorgesehenen Empfänger und exp den Ablaufzeitpunkt. Weitere häufige Angaben sind nbf für den frühesten Gültigkeitszeitpunkt, iat für den Ausstellungszeitpunkt und jti für eine eindeutige Token-ID.
Wie funktioniert ein JWT?
Nach einer erfolgreichen Anmeldung erzeugt der Authentifizierungsserver ein JSON Web Token und signiert Header sowie Payload. Der Client sendet das Token bei nachfolgenden Anfragen zurück, häufig im HTTP-Header Authorization: Bearer TOKEN. Der Zielserver prüft die Signatur und die erforderlichen Claims, bevor er den Zugriff erlaubt.
Die Signaturprüfung beantwortet nur die Frage, ob das JSON Web Token unverändert ist und mit dem erwarteten Schlüssel erstellt wurde. Sie beweist nicht automatisch, dass der aktuelle Nutzer weiterhin zugriffsberechtigt ist. Wurde ein Konto gesperrt oder eine Berechtigung entzogen, bleibt ein bereits ausgestelltes Token bis zum Ablauf gültig, sofern die Anwendung keine Sperrliste oder zusätzliche Statusprüfung verwendet.
Symmetrische und asymmetrische Signaturen
Bei einem symmetrischen Verfahren wie HMAC verwenden Aussteller und Prüfer dasselbe Geheimnis. Jeder Dienst, der das Token prüfen kann, könnte damit auch neue Tokens signieren. Asymmetrische Verfahren wie RSA oder ECDSA trennen diese Aufgaben: Der Aussteller signiert mit dem privaten Schlüssel, während andere Dienste nur den öffentlichen Schlüssel zur Prüfung erhalten.
Für verteilte Anwendungen ist die asymmetrische Signatur oft leichter kontrollierbar, weil prüfende Systeme keinen geheimen Signaturschlüssel benötigen. Die Anwendung muss trotzdem eine feste Liste zulässiger Algorithmen durchsetzen. Sie darf das im Header angegebene Verfahren nicht ungeprüft übernehmen.
JWT ist keine Verschlüsselung
Ein verbreiteter Denkfehler besteht darin, die Kodierung eines JSON Web Tokens mit Verschlüsselung gleichzusetzen. Header und Payload eines üblichen signierten Tokens lassen sich ohne geheimen Schlüssel dekodieren. Die Signatur schützt die Integrität, verbirgt aber weder Namen noch Rollen, E-Mail-Adressen oder andere Claims.
Vertrauliche Inhalte gehören deshalb nicht in die Payload eines gewöhnlichen JWT. Falls der Inhalt verborgen werden muss, ist ein verschlüsseltes JWE oder ein anderes geeignetes Übertragungsverfahren erforderlich. HTTPS bleibt in beiden Fällen notwendig, weil die Transportverschlüsselung das Token während der Übertragung vor dem Mitlesen schützt.
JWT, Session und Cookie unterscheiden
Der Unterschied zwischen JSON Web Token, Session und Cookie liegt in ihrer Funktion. Ein JWT ist ein Token-Format, eine Session ist ein serverseitiges Zustandsmodell und ein Cookie ist ein Speicher- und Übertragungsmechanismus des Browsers. Ein JSON Web Token kann daher in einem Cookie gespeichert werden, ist selbst aber kein Cookie.
| Begriff | Aufgabe | Typische Eigenschaft |
|---|---|---|
| JSON Web Token | Überträgt signierte oder verschlüsselte Claims | Kann dezentral geprüft werden |
| Server-Session | Speichert den Anmeldestatus auf dem Server | Der Client erhält meist nur eine Session-ID |
| Cookie | Speichert Daten im Browser und sendet sie an passende Domains | Kann eine Session-ID oder ein JWT enthalten |
Access Token und Refresh Token
Ein Access Token erlaubt den Zugriff auf geschützte Ressourcen und sollte eine begrenzte Gültigkeitsdauer besitzen. Ein Refresh Token dient dazu, ein neues Access Token anzufordern. Nicht jedes Access Token ist ein JWT, und auch ein Refresh Token muss nicht im JWT-Format vorliegen. Das jeweilige Protokoll bestimmt Format, Zweck und Prüfregeln.
Sichere Verwendung von JWT
Ein JSON Web Token ist nur so zuverlässig wie seine serverseitige Prüfung. Der Server muss mindestens Signatur, Ablaufzeit, Aussteller und Zielgruppe kontrollieren. Eine gültige Signatur reicht nicht aus, wenn das Token für eine andere Anwendung oder von einem unerwarteten Aussteller erstellt wurde.
Die Speicherung im Browser hängt vom Anwendungskonzept ab. Ein Cookie mit den Attributen HttpOnly, Secure und einem geeigneten SameSite-Wert erschwert den Zugriff durch eingeschleustes JavaScript, erfordert aber einen Schutz gegen Cross-Site Request Forgery. Ein Token im JavaScript-Speicher kann gezielt im Authorization-Header gesendet werden, ist bei einer Cross-Site-Scripting-Lücke jedoch direkt auslesbar.
Relevanz für SEO und Webentwicklung
Ein JSON Web Token beeinflusst Rankings nicht unmittelbar. SEO-Probleme entstehen, wenn öffentlich relevante Inhalte erst nach einer tokenbasierten Anmeldung geladen werden. Erhält ein Suchmaschinen-Crawler statt des Seiteninhalts den HTTP-Statuscode 401 oder 403, kann er die geschützten Informationen in der Regel nicht indexieren.
Produktseiten, Ratgeber, Standortseiten und andere organisch relevante Inhalte sollten ohne Anmeldung abrufbar und vollständig renderbar sein. Benutzerkonten, interne Dashboards und Bestellinformationen gehören dagegen in geschützte Bereiche. Ein technisches SEO-Audit prüft, welche Inhalte Crawler tatsächlich erreichen und ob Authentifizierungslogik unbeabsichtigt öffentliche URLs blockiert.
Bei neuen Plattformen sollte die Trennung zwischen öffentlichem Content und geschützten Anwendungsdaten bereits in der Architektur festgelegt werden. Eine auf Crawling, Ladezeit und saubere HTTP-Antworten ausgerichtete Webentwicklung mit SEO-Konzept reduziert spätere Anpassungen an Rendering und Zugriffskontrolle. Ergänzend kann ein kostenloser SEO-Check erste technische Auffälligkeiten öffentlich erreichbarer URLs sichtbar machen.
Häufige Fragen zu JWT
Kann man den Inhalt eines JWT lesen?
Ja. Header und Payload eines üblichen signierten JWT lassen sich dekodieren, weil Base64url keine Verschlüsselung ist. Ohne den passenden Schlüssel kann ein Angreifer den Inhalt zwar lesen, aber kein gültig signiertes Token verändern oder neu erstellen.
Wie lange sollte ein JWT gültig sein?
Die Gültigkeitsdauer hängt vom Risiko und vom Anwendungsfall ab. Zugriffstokens sollten möglichst kurz gültig sein, während längere Sitzungen über abgesicherte Refresh Tokens verwaltet werden können. Zusätzlich braucht die Anwendung ein Verfahren für Sperrung, Abmeldung und Schlüsselwechsel.
Wo wird ein JWT gespeichert?
Ein JWT kann beispielsweise in einem HttpOnly-Cookie oder vorübergehend im Arbeitsspeicher einer Anwendung gespeichert werden. Die Wahl muss sowohl Cross-Site Scripting als auch Cross-Site Request Forgery berücksichtigen. Dauerhafte Browser-Speicher erhöhen die Folgen einer erfolgreichen Script-Injektion.
Was passiert, wenn ein JWT abgelaufen ist?
Ein Server muss ein JWT nach dem im Claim exp angegebenen Zeitpunkt ablehnen. Der Client meldet den Nutzer anschließend erneut an oder fordert mit einem gültigen Refresh Token ein neues Access Token an. Eine kleine tolerierte Zeitabweichung zwischen Servern muss klar begrenzt sein.
Kann ein JWT widerrufen werden?
Ein JWT kann vor seinem Ablauf widerrufen werden, wenn die Anwendung dafür eine Sperrliste, eine Token-Version oder eine serverseitige Statusprüfung vorsieht. Ohne einen solchen Mechanismus bleibt ein korrekt signiertes Token normalerweise bis zum Ablaufzeitpunkt nutzbar.
Ist JWT dasselbe wie OAuth?
Nein. OAuth ist ein Protokollrahmen für delegierte Autorisierung, während JWT ein Format für die Übertragung von Claims ist. OAuth kann JWT als Access Token verwenden, erlaubt aber auch Tokens in anderen Formaten.
Wenn eine tokenbasierte Webanwendung öffentlich sichtbare Inhalte ausliefert, sollte die technische Architektur gemeinsam mit Crawling und Indexierung geprüft werden.
Sie haben noch Fragen?
