JSON Web Token (JWT)

Ein JSON Web Token (JWT) wird in der Webentwicklung vor allem für Anmeldung, Autorisierung und abgesicherte API-Aufrufe eingesetzt. Die deutsche Bezeichnung JSON-Web-Token ist unüblich. Anwendungen verwenden das Token beispielsweise, um nach einer erfolgreichen Anmeldung die Identität und Berechtigungen eines Nutzers bei weiteren Anfragen zu prüfen.

Wie funktioniert ein JSON Web Token (JWT)?

Ein Server erstellt ein JSON Web Token (JWT), nachdem er einen Nutzer oder ein anderes System authentifiziert hat. Das Token wird an den Client übertragen und bei späteren Anfragen mitgesendet. Der empfangende Server kontrolliert die Signatur sowie zeitliche und inhaltliche Bedingungen, bevor er den Zugriff auf eine Ressource erlaubt.

Ein verbreiteter Ablauf besteht aus vier Schritten:

• Der Nutzer meldet sich mit seinen Zugangsdaten an.
• Der Server prüft die Angaben und erstellt ein signiertes JWT.
• Der Client sendet das Token bei einer API-Anfrage mit, häufig im HTTP-Header Authorization: Bearer TOKEN.
• Der Server validiert Signatur, Gültigkeitszeitraum, Aussteller und Empfänger des Tokens.

Der Server muss für jede Anfrage alle vorgesehenen Prüfungen durchführen. Eine gültige Signatur allein reicht nicht aus, wenn das Token beispielsweise abgelaufen ist, für einen anderen Dienst ausgestellt wurde oder eine erforderliche Berechtigung fehlt.

Aufbau eines JWT

Ein signiertes JSON Web Token besteht normalerweise aus drei Zeichenfolgen, die durch Punkte getrennt sind: Header.Payload.Signatur. Header und Payload werden mit Base64url kodiert. Diese Kodierung macht die Daten transportfähig, verschlüsselt sie aber nicht. Jeder, der das Token erhält, kann den Inhalt dieser beiden Bereiche grundsätzlich dekodieren.

Header: Typ und Verfahren

Der Header benennt üblicherweise den Token-Typ und das verwendete Signaturverfahren. Ein vereinfachter Header kann {"typ":"JWT","alg":"HS256"} enthalten. Die Anwendung darf den angegebenen Algorithmus nicht ungeprüft übernehmen, sondern muss eine feste Liste erlaubter Verfahren vorgeben.

Payload: Claims mit Informationen

Die Payload enthält sogenannte Claims. Ein Claim ist eine Aussage über den Nutzer, den Aussteller oder die Gültigkeit des Tokens. Häufig verwendete registrierte Claims sind sub für das Subjekt, iss für den Aussteller, aud für den vorgesehenen Empfänger und exp für den Ablaufzeitpunkt.

Signatur: Integrität statt Geheimhaltung

Die Signatur wird aus den kodierten Header- und Payload-Daten sowie einem Schlüssel berechnet. Bei symmetrischen Verfahren verwenden Aussteller und Prüfer dasselbe Geheimnis. Bei asymmetrischen Verfahren signiert ein privater Schlüssel das Token, während ein öffentlicher Schlüssel die Signatur prüft.

JWT-Sicherheit 2026

Der häufigste Denkfehler besteht darin, ein erfolgreich dekodiertes JSON Web Token mit einem gültigen Token gleichzusetzen. Dekodieren bedeutet lediglich, die Base64url-Daten lesbar zu machen. Erst die kryptografische Prüfung der Signatur zeigt, ob ein vertrauenswürdiger Aussteller das Token signiert hat und ob Header oder Payload verändert wurden.

Eine belastbare JWT-Prüfung berücksichtigt mindestens folgende Bedingungen:

• Die Signatur stimmt und der verwendete Algorithmus ist ausdrücklich erlaubt.
• Der in exp angegebene Ablaufzeitpunkt wurde noch nicht überschritten.
• Ein vorhandener nbf-Wert erlaubt die Nutzung bereits.
• Der Claim iss entspricht dem erwarteten Aussteller.
• Der Claim aud nennt den aufgerufenen Dienst als Empfänger.
• Die erforderlichen Rollen oder Berechtigungen sind tatsächlich enthalten.

Kurze Gültigkeitszeiten begrenzen den Zeitraum, in dem ein gestohlenes Access Token nutzbar bleibt. Für längere Sitzungen kann eine Anwendung zusätzlich ein Refresh Token verwenden, das ein neues Access Token anfordert. Refresh Tokens benötigen einen besonders geschützten Speicher und eine Möglichkeit zur Sperrung oder Rotation.

JWT oder Session: der Unterschied

Der Unterschied zwischen einem JSON Web Token und einer serverseitigen Session liegt im Speicherort des Sitzungszustands. Bei einer klassischen Session speichert der Server die Sitzungsdaten und der Browser erhält nur eine zufällige Session-ID. Ein JWT trägt die für die Prüfung benötigten Claims dagegen im Token selbst.

JWT ist nicht automatisch die bessere Lösung. Eine klassische Webanwendung mit zentralem Server kann Sitzungen oft einfacher kontrollieren und unmittelbar beenden. Ein JSON Web Token bietet Vorteile, wenn mehrere APIs oder Dienste dieselben überprüfbaren Identitätsinformationen benötigen.

JWT in der Webentwicklung

In der Website-Entwicklung mit technischer und SEO-orientierter Grundlage kommt JWT häufig bei Single-Page-Anwendungen, mobilen Apps, Headless-Systemen und Microservices zum Einsatz. Ein Frontend kann damit geschützte Daten von einer API abrufen, ohne bei jeder Anfrage Benutzername und Passwort zu übertragen.

Der Speicherort des Tokens beeinflusst das Sicherheitsmodell. JavaScript kann auf Werte in localStorage zugreifen, wodurch eingeschleuster Schadcode auch dort gespeicherte Tokens auslesen kann. Ein Cookie mit der Eigenschaft HttpOnly ist für JavaScript nicht lesbar, erfordert aber einen konsequenten Schutz vor Cross-Site Request Forgery. Die passende Lösung hängt deshalb von Architektur, Bedrohungsmodell und Anmeldeprozess ab.

Relevanz für SEO, SEA und GEO

Ein JSON Web Token verbessert keine Rankings und erhöht nicht direkt die SEO-Sichtbarkeit. JWT kann Suchmaschinen jedoch den Zugriff auf Inhalte erschweren, wenn redaktionelle Seiten erst nach einer tokenbasierten Anmeldung oder ausschließlich über geschützte APIs geladen werden. Öffentlich relevante Inhalte sollten ohne Authentifizierung abrufbar und im initialen HTML oder über zuverlässig renderbare Prozesse verfügbar sein.

Bei SEA-Landingpages können fehlerhafte Token-Abläufe zu abgebrochenen Formularen, fehlenden Warenkörben oder unvollständigem Conversion-Tracking führen. Eine technische Prüfung von Google-Ads-Zielseiten sollte deshalb auch Authentifizierung, Weiterleitungen und API-Fehler berücksichtigen.

Für GEO, also Generative Engine Optimization, gilt dieselbe Zugriffslogik: Informationen hinter einer Anmeldung oder in einer geschützten API können von öffentlich arbeitenden Such- und KI-Systemen normalerweise nicht als Quelle abgerufen werden. Inhalte, die in KI-Antworten auffindbar sein sollen, benötigen eine öffentlich zugängliche, klar strukturierte Webversion.

Typische Fehler bei JSON Web Tokens

Probleme entstehen meist durch eine unvollständige Validierung oder eine zu großzügige Gültigkeit. Ein Server sollte ein JWT niemals allein deshalb akzeptieren, weil es korrekt aufgebaut ist oder sich fehlerfrei dekodieren lässt.

• Die Signatur wird nicht geprüft oder ungeeignete Algorithmen werden zugelassen.
• Der Ablaufzeitpunkt exp fehlt oder wird ignoriert.
• Vertrauliche Informationen stehen lesbar in der Payload.
• Ein gestohlenes Token bleibt über einen langen Zeitraum gültig.
• Tokens erscheinen in URLs und gelangen dadurch in Logs, Browserverläufe oder Referrer-Daten.
• Schlüssel werden direkt im Quellcode gespeichert und gemeinsam mit der Anwendung veröffentlicht.

Eine sichere Umsetzung prüft das vollständige Token auf der Serverseite, begrenzt die Berechtigungen und protokolliert abgelehnte Zugriffe ohne das komplette Token zu speichern. Bei einer neuen Anwendung sollte die Authentifizierungsarchitektur bereits vor der technischen Umsetzung feststehen. Die Checkliste für neue Websites und Webanwendungen hilft dabei, technische Anforderungen früh in die Planung aufzunehmen.

Häufige Fragen zu JWT

Wenn tokenbasierte Anmeldung, APIs und öffentliche Inhalte in einer Website zusammenspielen, sollte die Architektur SEO, Tracking und Zugriffsschutz gemeinsam berücksichtigen.

Kostenlose Beratung