Was ist JWT? Ein vollständiger Leitfaden zu JSON Web Tokens

Was ist JWT?

JSON Web Token (JWT) ist ein offener Standard (RFC 7519), der eine kompakte, in sich geschlossene Möglichkeit definiert, Informationen zwischen Parteien sicher als JSON-Objekt zu übertragen. JWTs sind das dominierende Token-Format in modernen Webanwendungen und werden für alles verwendet, von der Benutzerauthentifizierung und API-Autorisierung bis hin zum sicheren Datenaustausch zwischen Microservices.

Wie die JWT-Authentifizierung funktioniert

Die JWT-Authentifizierung folgt einem zustandslosen Muster, das die Notwendigkeit serverseitiger Sitzungsspeicherung überflüssig macht. Das Verständnis dieses Ablaufs ist der Schlüssel zum Verständnis, warum JWTs zur Standardwahl für die Sicherheit moderner APIs geworden sind.

Der Authentifizierungsablauf

1. Der Benutzer meldet sich an – Der Client sendet Anmeldedaten (Benutzername und Passwort) an den Authentifizierungsserver.
2. Der Server erstellt ein JWT – Der Server validiert die Anmeldedaten, erstellt ein JWT mit der Identität und den Berechtigungen des Benutzers, signiert es mit einem geheimen oder privaten Schlüssel und gibt es an den Client zurück.
3. Der Client speichert das Token – Der Client speichert das JWT, in der Regel in localStorage, sessionStorage oder einem HTTP-only-Cookie.
4. Der Client sendet das Token mit jeder Anfrage – Für jede nachfolgende API-Anfrage fügt der Client das JWT in den Authorization-Header ein, unter Verwendung des Bearer-Schemas: Authorization: Bearer <token>.
5. Der Server verifiziert das Token – Der Server verifiziert die JWT-Signatur, prüft die Ablaufzeit und extrahiert die Benutzer-Claims, um die Anfrage zu autorisieren.
6. Keine Sitzungsabfrage erforderlich – Da das JWT alle notwendigen Informationen enthält, muss der Server keine Datenbank oder keinen Cache abfragen, um den Benutzer zu identifizieren.

Warum dies wichtig ist

Traditionelle sitzungsbasierte Authentifizierung speichert Sitzungs-IDs im Speicher oder in der Datenbank des Servers. Jede authentifizierte Anfrage erfordert eine Abfrage. JWTs machen diese Abfrage überflüssig – das Token selbst beweist die Identität des Benutzers. Dies macht JWT-basierte Systeme von Natur aus skalierbar, da jeder Server in einem Cluster ein Token ohne gemeinsamen Sitzungszustand verifizieren kann.

JWT im Vergleich zur sitzungsbasierten Authentifizierung

| Aspekt | JWT-Authentifizierung | Sitzungsbasierte Authentifizierung | |--------|--------------------|------------------------------| | Speicherung | Clientseitig (im Token) | Serverseitig (im Speicher oder in der DB) | | Skalierbarkeit | Kein gemeinsamer Sitzungsspeicher erforderlich | Erfordert gemeinsamen Sitzungsspeicher über Instanzen hinweg | | Cross-Domain | Funktioniert natürlich über Domains hinweg | Sitzungen sind schwer zu teilen | | Mobilfreundlich | Ja (keine Cookies erforderlich) | Erfordert Cookie-Unterstützung | | Widerruf | Schwierig (bis das Token abläuft) | Einfach (Sitzung aus dem Speicher löschen) | | Payload-Größe | Größer pro Anfrage (Token im Header) | Minimal (nur Sitzungs-ID) |

Warum JWT für die API-Sicherheit verwendet wird

Die Eigenschaften, die JWT für die Authentifizierung geeignet machen, machen es auch ideal für die Absicherung von APIs.

Zustandslos und skalierbar

Jedes JWT enthält alle Informationen, die der Server benötigt, um eine Anfrage zu autorisieren. Es gibt keine Sitzungsdatenbank, die abgefragt werden muss, keinen Cache, der geprüft werden muss, keinen Zustand, der über Server hinweg synchronisiert werden muss. Lastverteiler können Anfragen ohne Abstimmung an jede Serverinstanz weiterleiten.

Cross-Domain und Cross-Origin

JWT funktioniert natürlich über verschiedene Domains und Origins hinweg. Ein Token, das von auth.example.com ausgestellt wurde, kann verwendet werden, um auf api.example.com und admin.example.com zuzugreifen. Dies macht JWT zur Grundlage von Single-Sign-On-Systemen (SSO).

Fein granulierte Autorisierung

Die JWT-Payload kann benutzerdefinierte Claims für Rollen, Berechtigungen und Organisationsmitgliedschaften enthalten:

{
  "sub": "user_abc123",
  "role": "admin",
  "permissions": ["read:users", "write:users", "delete:users"],
  "org_id": "org_xyz789",
  "iat": 1516239022,
  "exp": 1516325422
}

Der API-Server liest diese Claims direkt aus dem Token, ohne zusätzliche Abfragen.

JWT für Single Sign-On (SSO)

Single Sign-On ist einer der häufigsten JWT-Anwendungsfälle. In einer typischen SSO-Architektur:

1. Ein Benutzer meldet sich beim Identity Provider (IdP) an – etwa bei Auth0, Okta oder Keycloak.
2. Der IdP gibt ein JWT aus, das mit seinem privaten Schlüssel signiert ist.
3. Der Benutzer legt dieses JWT mehreren Anwendungen vor.
4. Jede Anwendung verifiziert die Signatur mit dem öffentlichen Schlüssel des IdP.
5. Jede Anwendung vertraut dem Token, ohne bei jeder Anfrage mit dem IdP zu kommunizieren.

Dieses Muster ermöglicht es, dass eine einzige Anmeldung Zugriff auf Dutzende von Diensten gewährt – E-Mail, Dateispeicher, Projektmanagement, HR-Systeme – ohne dass jeder Dienst seinen eigenen Anmeldeablauf implementiert.

JWT-Sicherheits-Best Practices

Obwohl JWT eine starke Grundlage für die API-Sicherheit bietet, ist eine korrekte Implementierung unerlässlich.

Halten Sie Tokens kurzlebig

Legen Sie den exp-Claim (Ablaufzeit) auf eine kurze Dauer fest – 15 Minuten bis 1 Stunde für Zugriffstokens. Verwenden Sie langlebigere Refresh-Tokens (Tage oder Wochen), um neue Zugriffstokens zu erhalten, ohne dass der Benutzer sich erneut authentifizieren muss.

Verwenden Sie immer HTTPS

JWT verschlüsselt seine Payload nicht. Jeder, der das Token abfängt, kann seinen Inhalt decodieren und lesen. Übertragen Sie JWTs immer über HTTPS, um Abfangen zu verhindern.

Validieren Sie alles

Verifizieren Sie immer die Signatur, prüfen Sie, dass das Token nicht abgelaufen ist, bestätigen Sie, dass der aud-Claim (Audience) zu Ihrer Anwendung passt, und lehnen Sie Tokens mit unerwarteten Algorithmen ab.

Speichern Sie Tokens sicher

Speichern Sie JWTs auf der Clientseite, wenn möglich, in HTTP-only-Cookies oder im Speicher für Single-Page-Anwendungen. Vermeiden Sie localStorage für Tokens, die Zugriff auf sensible Daten gewähren.

Häufige JWT-Irrtümer

„JWT ist verschlüsselt.“ – Nein. JWT ist signiert, nicht verschlüsselt. Die Payload ist base64url-codiert, was umkehrbar ist. JWE (JSON Web Encryption) bietet Verschlüsselung, ist aber eine separate Spezifikation, die nicht vom Standard-JWT abgedeckt wird.

„JWT verhindert CSRF.“ – Nicht von sich aus. JWT in einem Authorization-Header hilft, aber wenn sich das Token in einem Cookie befindet, ist CSRF-Schutz weiterhin erforderlich.

„JWT dient nur der Authentifizierung.“ – JWT wird für die Authentifizierung verwendet, aber auch für den Austausch von Autorisierungsdaten, zustandslose Sitzungen und das sichere Teilen von Informationen zwischen Diensten.

Decodieren und erkunden Sie JWT online

Nutzen Sie das JWT-Decoder-Tool, um jedes JSON Web Token zu untersuchen. Fügen Sie Ihr Token ein und sehen Sie sofort den decodierten Header, die Payload und den Signaturalgorithmus. Das Tool hilft Ihnen zu verstehen, welche Daten Ihre Tokens enthalten, und zu überprüfen, dass sie korrekt strukturiert sind.