Ein JWT-Token, kurz für JSON Web Token, ist ein kompaktes Format zum Übertragen von Claims zwischen zwei Parteien. Anwendungen verwenden JWTs häufig nach der Anmeldung: Ein Server stellt ein Token aus, der Client sendet es bei späteren Anfragen mit, und eine API verifiziert das Token, bevor sie den Zugriff erlaubt. Ein JWT ist kein Kryptowährungs-Token, und seine Inhalte sind nicht automatisch geheim.
Konto-Systeme in den Bereichen Finanzen, Börsen und Web3-Dienste können im Hintergrund tokenbasierte Authentifizierung nutzen. Leser, die digitale Asset-Plattformen erkunden, können ein Tapbit-Konto erstellen, während Entwickler jedes Authentifizierungs-Token als sicherheitsrelevantes Anmeldeinformation behandeln sollten.
Was ist ein JWT-Token?
Der JWT-Standard, RFC 7519, definiert ein kompaktes Claims-Format, das für die Übertragung als JSON-Objekt konzipiert ist. Ein Claim ist eine Aussage wie eine Benutzerkennung, ein Token-Aussteller, eine beabsichtigte Zielgruppe oder eine Ablaufzeit. JWTs werden oft als Zugriffstoken, Identitätstoken oder kurzlebige Nachrichten zwischen Diensten verwendet.
Leute sagen oft “JWT-Token”, obwohl das letzte “T” bereits Token bedeutet. Die Wiederholung ist üblich und harmlos. Wichtig ist zu verstehen, dass JWT ein Format beschreibt, kein vollständiges Anmeldesystem. Sichere Authentifizierung erfordert auch korrekte Richtlinien für Ausstellung, Validierung, Speicherung, Ablauf und Widerruf.
Wie funktioniert ein JSON Web Token?
Ein typischer Anmeldevorgang beginnt, wenn ein Benutzer gültige Anmeldeinformationen übermittelt. Der Authentifizierungsserver erstellt ein JWT mit ausgewählten Claims und schützt es mit einer digitalen Signatur oder einem Message Authentication Code. Der Client präsentiert dann das JWT einer API, oft in einem HTTP-Autorisierungsheader mit dem Bearer-Schema.
Die API verifiziert die Signatur und prüft erforderliche Claims, bevor sie die Anfrage vertraut. Wichtige Prüfungen können den Aussteller, die Zielgruppe, die Ablaufzeit und den von der Anwendung erwarteten Algorithmus umfassen. Wenn die Verifizierung erfolgreich ist, verwendet die API die Claims, um eine Autorisierungsentscheidung zu treffen. Wenn sie fehlschlägt, sollte die Anfrage abgelehnt werden.
Die drei Teile eines JWT
Ein häufig anzutreffendes signiertes JWT hat drei Base64url-kodierte Abschnitte, die durch Punkte getrennt sind:
header.payload.signature
- Header: Identifiziert den Token-Typ und den Signaturalgorithmus.
- Payload: Enthält Claims wie
subfür Subjekt,issfür Aussteller,audfür Zielgruppe undexpfür Ablaufdatum. - Signatur: Ermöglicht dem Empfänger, unbefugte Änderungen zu erkennen und den Unterzeichner zu verifizieren, wenn der richtige Schlüssel verwendet wird.
Base64url-Kodierung ist keine Verschlüsselung. Jeder, der ein normales signiertes JWT erhält, kann in der Regel seinen Header und seine Payload dekodieren. Sensible Informationen sollten daher nicht in die Payload aufgenommen werden, es sei denn, das System verwendet ein geeignetes verschlüsseltes Format und hat einen klaren Bedarf dafür.
JWT-Beispiel für Anfänger
Stellen Sie sich eine API vor, die nach Alices Anmeldung ein Token ausstellt. Ihre Payload könnte Alice als Subjekt identifizieren, den Aussteller benennen, die API als Zielgruppe festlegen und in 15 Minuten ablaufen. Wenn Alice ihr Profil anfordert, validiert die API das Token und verwendet den Subjekt-Claim, um das richtige Konto zu finden.
Wenn jemand die Payload von Alices Kennung in die Kennung eines Administrators ändert, stimmt die Signatur nicht mehr überein. Das ist der Kernvorteil eines signierten JWT: Manipulation wird erkennbar. Eine gültige Signatur beweist jedoch nicht, dass jeder Claim angemessen ist. Die API muss immer noch bestätigen, dass das Token vom erwarteten Aussteller stammt und für diese API bestimmt war.
JWT vs. Session-Cookies vs. API-Schlüssel
| Methode | Typischer Zweck | Wo der Zustand lebt | Hauptüberlegung |
|---|---|---|---|
| JWT | Claims und API-Autorisierung | Token trägt Claims; Server können immer noch Zustand speichern | Design von Validierung und Widerruf |
| Session-Cookie | Browser-Anmeldesitzung | Normalerweise serverseitiger Session-Speicher | Cookie- und CSRF-Schutz |
| API-Schlüssel | Identifizierung einer Anwendung oder eines Projekts | Server ordnet Schlüssel Berechtigungen zu | Schlüssel sind langlebige Geheimnisse, es sei denn, sie werden rotiert |
JWTs sind nicht automatisch besser als Sessions. Sessions können den sofortigen Widerruf unkompliziert machen, während JWTs wiederholte Datenbankabfragen reduzieren und gut über verteilte Dienste hinweg funktionieren können. Viele Systeme kombinieren beide Ansätze, z. B. ein kurzlebiges JWT mit einem serverseitig verwalteten Refresh-Token-Datensatz.
Sind JWTs verschlüsselt?
Normalerweise nicht. Das bekannte dreiteilige JWT ist üblicherweise ein signiertes JSON Web Signature-Objekt. Die Signierung bietet Integrität und Authentizität, wenn sie korrekt implementiert ist, aber sie verbirgt die Payload nicht. JSON Web Encryption ist ein verwandter Standard, der Vertraulichkeit bieten kann, obwohl er eine andere Struktur verwendet und die Komplexität der Schlüsselverwaltung erhöht.
Dieser Unterschied ist wichtig, da Entwickler manchmal ein JWT in einen Decoder einfügen und überrascht sind, lesbare Daten zu sehen. Dekodieren ist nicht dasselbe wie die erfolgreiche Verifizierung der Signatur. Anwendungen sollten niemals nur auf dekodierten Claims basierend Zugriff gewähren.
Häufige JWT-Sicherheitsrisiken
Die JWT Best Current Practices, RFC 8725, des IETF adressieren Implementierungsfehler, die in realen Systemen aufgetreten sind. Die größten Probleme entstehen meist durch falsche Validierung und nicht durch das grundlegende Format selbst.
- Algorithmus-Verwechslung: Akzeptieren eines unerwarteten oder unsicheren Algorithmus.
- Fehlende Claim-Prüfungen: Ignorieren von Aussteller, Zielgruppe, Ablaufdatum oder anderen Anwendungsanforderungen.
- Token-Diebstahl: Offenlegung eines Bearer-Tokens durch Protokolle, Skripte, unsichere Speicherung oder ungeschützten Transport.
- Schwache Schlüssel: Verwendung von erratbaren Geheimnissen oder Versäumnis, kompromittierte Signierschlüssel zu rotieren.
- Langer Ablauf: Gestohlene Token bleiben zu lange nutzbar.
- Schlechter Widerruf: Annahme, dass ein signiertes Token niemals vorzeitig ungültig gemacht werden kann.
JWT-Best Practices
Anwendungen sollten explizit nur die von ihnen unterstützten Algorithmen zulassen, jeden erforderlichen Claim überprüfen und separate Validierungsregeln für verschiedene Arten von JWTs verwenden. Token sollten kurzlebig sein, nur über HTTPS übertragen und von URLs und routinemäßigen Protokollen ausgeschlossen werden. Signierschlüssel benötigen sichere Speicherung, Rotation und klare Zuständigkeit.
Die Speicherung hängt von der Anwendung ab. Browser-Systeme können sichere, HttpOnly- und SameSite-Cookies verwenden, während mobile oder Backend-Clients plattformspezifisch geschützte Speicher verwenden. Keine Speicherwahl beseitigt jede Bedrohung, daher müssen Entwickler Cross-Site-Scripting, Cross-Site-Request-Forgery, Token-Wiederholung und Gerätekompromittierung gemeinsam berücksichtigen.
Schlussfolgerung
Ein JWT ist eine kompakte Methode, um verifizierbare Claims zwischen Systemen zu übertragen. Sein Header beschreibt, wie er geschützt ist, seine Payload enthält Claims und seine Signatur hilft Empfängern, Manipulationen zu erkennen. JWTs können die API-Authentifizierung vereinfachen, aber nur, wenn der Empfänger den richtigen Algorithmus, Aussteller, Zielgruppe, Zeit-Claims und die Signatur überprüft. Für Anfänger ist die wichtigste Regel einfach: Ein JWT ist ein Anmeldeinformationsformat, kein Beweis dafür, dass ein gesamtes Authentifizierungsdesign sicher ist.
Häufig gestellte Fragen
Wofür steht JWT?
JWT steht für JSON Web Token, ein standardisiertes kompaktes Format zur Übertragung von Claims als JSON.
Kann jeder ein JWT dekodieren?
Jeder, der ein typisches signiertes JWT besitzt, kann in der Regel seinen Header und seine Payload dekodieren. Dekodierung verifiziert nicht die Signatur und macht die Claims nicht vertrauenswürdig.
Ist ein JWT dasselbe wie ein Zugriffstoken?
Nein. Ein Zugriffstoken beschreibt einen Zweck, während JWT ein Format beschreibt. Einige Zugriffstoken sind JWTs, andere sind undurchsichtige Zeichenketten.
Wie lange sollte ein JWT gültig sein?
Es gibt keine universelle Dauer. Zugriffstoken sind üblicherweise kurzlebig, wobei die genaue Lebensdauer auf den Risiko-, Widerrufs- und Nutzungsanforderungen des Systems basiert.
Kann ein JWT widerrufen werden?
Ja, aber der Widerruf erfordert zusätzliches Design, wie eine Denylist, Schlüsselrotation, Token-Versionierung oder ein serverseitig verwaltetes Refresh-Token-System.
