17. Okt. 2025·5 Min
Was ist JWT? Ein klarer Leitfaden zu JSON Web Tokens
Erfahre, was ein JWT (JSON Web Token) ist, wie Header, Payload und Signatur funktionieren, wo JWTs eingesetzt werden und welche Sicherheitsregeln du beachten solltest.
Erfahre, was ein JWT (JSON Web Token) ist, wie Header, Payload und Signatur funktionieren, wo JWTs eingesetzt werden und welche Sicherheitsregeln du beachten solltest.
Ein JWT (JSON Web Token) ist eine kompakte, URL‑sichere Zeichenkette, die eine Menge Informationen (meist über einen Benutzer oder eine Sitzung) darstellt und zwischen Systemen übertragen werden kann. Du siehst es oft als einen langen Wert, der mit etwas wie eyJ... beginnt, und der in einem HTTP‑Header wie Authorization: Bearer <token> gesendet wird.
Traditionelle Logins basieren häufig auf Server‑Sessions: Nach dem Anmelden speichert der Server Sitzungsdaten und gibt dem Browser ein Session‑ID‑Cookie. Jede Anfrage enthält dieses Cookie und der Server liest die Session aus.
Bei tokenbasierter Authentifizierung muss der Server nicht für jede Benutzeranfrage Sitzungszustand vorhalten. Stattdessen hält der Client ein Token (z. B. ein JWT) und hängt es an API‑Aufrufe an. Das ist besonders für APIs praktisch, weil es:
Wichtige Nuance: “stateless” heißt nicht “keine serverseitigen Prüfungen”. Viele reale Systeme validieren Tokens zusätzlich gegen Benutzerstatus, rotierende Schlüssel oder Widerrufsmechanismen.
JWTs tragen häufig den Beleg der Authentifizierung (du bist angemeldet) und einfache Autorisierungs‑Hinweise (Rollen, Berechtigungen, Scopes) — deine Serverlogik muss Autorisierungsregeln trotzdem durchsetzen.
JWTs werden oft als Access Tokens verwendet in:
Ein JWT ist eine kompakte Zeichenkette aus drei Teilen, jeweils base64url‑kodiert und durch Punkte getrennt:
header.payload.signature
Beispiel (redigiert):
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwiaWF0IjoxNzAwMDAwMDAwfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c…
Der Header beschreibt, wie das Token erzeugt wurde — am wichtigsten ist der Signaturalgorithmus (z. B. HS256, RS256/ES256) und der Token‑Typ.
Gängige Felder:
typ: oft "JWT" (wird in der Praxis häufig ignoriert)alg: der verwendete Signaturalgorithmuskid: Key Identifier, damit der Verifizierer beim Schlüsselwechsel den richtigen Schlüssel auswählen kannSicherheits‑Hinweis: Vertraue dem Header nicht blind. Erzwinge eine Allowlist der Algorithmen, die du tatsächlich verwendest, und akzeptiere nicht alg: "none".
Der Payload enthält "Claims" (Felder) über den Benutzer und den Token‑Kontext: für wen er gilt, wer ihn erstellt hat und wann er abläuft.
Wichtig: JWTs sind standardmäßig nicht verschlüsselt. Base64url kodiert macht das Token URL‑sicher; es verbirgt die Daten nicht. Jeder, der das Token bekommt, kann Header und Payload decodieren.
Deshalb solltest du vermeiden, Geheimnisse (Passwörter, API‑Schlüssel) oder sensible persönliche Daten in einem JWT zu speichern.
Die Signatur wird erzeugt, indem Header + Payload mit einem Schlüssel signiert werden:
Die Signatur stellt die Integrität sicher: Sie erlaubt dem Server zu prüfen, dass das Token nicht verändert wurde und von einem vertrauenswürdigen Signierer stammt. Sie sorgt nicht für Vertraulichkeit.
Weil ein JWT Header und Payload bei jeder Anfrage mitschickt, bedeutet größere Tokens mehr Bandbreite und Overhead. Halte Claims schlank und bevorzuge Identifikatoren statt umfangreicher Daten.
Claims fallen meist in zwei Kategorien: registered (standardisierte Namen) und custom (anwendungsspezifische Felder).
Nimm nur auf, was der empfangende Dienst wirklich braucht, um eine Autorisierungsentscheidung zu treffen.
Gute Beispiele:
user_id)Vermeide "Bequemlichkeits‑Claims", die viele Profildaten duplizieren. Sie blähen das Token auf, werden schnell veraltet und erhöhen den Schaden, wenn das Token leakt.
Da der Payload lesbar ist, solltest du nicht speichern:
Wenn du sensible Informationen benötigst, speichere sie serverseitig und lege nur eine Referenz (z. B. eine ID) in das Token — oder nutze ein verschlüsseltes Token‑Format (JWE), wenn angemessen.
Signieren ist nicht Verschlüsseln.
Wenn ein JWT ausgestellt wird, signiert der Server den kodierten Header + Payload. Wird das Token später vorgelegt, berechnet der Server die Signatur neu und vergleicht sie. Wenn auch ein Zeichen geändert wurde (z. B. "role":"user" zu "role":"admin"), schlägt die Verifikation fehl und das Token wird abgelehnt.
JWT ist ein Tokenformat. OAuth 2.0 und OpenID Connect (OIDC) sind Protokolle, die beschreiben, wie Apps Tokens anfordern und verwenden.
OAuth 2.0 dreht sich hauptsächlich um Autorisierung: einer App Zugriff auf eine API im Namen eines Nutzers zu gewähren, ohne das Passwort zu teilen.
Access Tokens sind typischerweise kurzlebig (Minuten). Kurze Lebenszeiten begrenzen den Schaden, falls ein Token leakiert.
OIDC ergänzt OAuth 2.0 um Authentifizierung und führt das ID Token ein, das gewöhnlich ein JWT ist.
Eine wichtige Regel: verwende kein ID Token, um eine API aufzurufen.
Wenn du mehr zu praktischen Flows möchtest, siehe /blog/jwt-authentication-flow.
Ein typischer Ablauf sieht so aus:
Der Nutzer meldet sich an (E‑Mail/Passwort, SSO, etc.). Bei Erfolg erzeugt der Server ein JWT (oft ein Access Token) mit wesentlichen Claims wie Subject und Ablaufzeit.
Der Server signiert das Token und gibt es an den Client zurück (Web‑App, Mobile‑App oder ein anderer Dienst).
Für geschützte Endpunkte sendet der Client das JWT im Authorization‑Header:
Authorization: Bearer <JWT>
Vor der Bearbeitung prüft die API typischerweise:
exp (nicht abgelaufen)iss (erwarteter Aussteller)aud (für diese API gedacht)Wenn alle Prüfungen bestanden sind, behandelt die API den Benutzer als authentifiziert und wendet Autorisierungsregeln an (z. B. zeilenbasierte Berechtigungen).
Da Systemuhren abweichen können, erlauben viele Systeme eine kleine Clock‑Skew‑Toleranz bei der Validierung zeitbasierter Claims wie exp (und manchmal nbf). Halte die Toleranz klein, damit die Token‑Gültigkeit nicht ungewollt verlängert wird.
Die Speicheroption beeinflusst, welche Angreifer Tokens stehlen können und wie leicht sie Tokens wiederverwenden.
In‑Memory (oft empfohlen für SPAs) speichert das Access Token im JavaScript‑Zustand. Es verschwindet beim Neuladen und reduziert das Risiko, es später zu stehlen, aber ein aktiver XSS‑Angriff kann es während der Laufzeit lesen. Kombiniere das mit kurzlebigen Access Tokens und einem Refresh‑Flow.
localStorage/sessionStorage sind bequem, aber riskant: jede XSS‑Lücke kann Tokens aus dem Web‑Speicher exfiltrieren. Wenn du sie verwendest, setze auf strikte XSS‑Prävention (CSP, korrektes Escaping, saubere Abhängigkeiten) und kurze Token‑Lebensdauern.
Sichere Cookies (häufig die sicherste Standardwahl fürs Web) speichern Tokens in einem HttpOnly‑Cookie, sodass JavaScript sie nicht lesen kann—das reduziert die Auswirkungen eines XSS‑Diebstahls. Der Nachteil ist ein CSRF‑Risiko, da Browser Cookies automatisch mitschicken.
Wenn du Cookies nutzt, setze:
HttpOnlySecure (nur HTTPS)SameSite=Lax oder SameSite=Strict (bei bestimmten Cross‑Site‑Flows SameSite=None; Secure)Ziehe zusätzlich CSRF‑Token für zustandsändernde Anfragen in Betracht.
Auf iOS/Android speichere Tokens im plattformsicheren Speicher (Keychain / Keystore‑gesicherter Speicher). Vermeide einfache Dateien oder Preferences. Wenn dein Bedrohungsmodell gerootete/jailbroken Geräte einschließt, rechne damit, dass Extraktion möglich ist und verlasse dich auf kurzlebige Tokens und serverseitige Kontrollen.
Beschränke, was ein Token darf: nutze minimale Scopes/Claims, halte Access Tokens kurzlebig und vermeide das Einbetten sensibler Daten.
JWTs sind praktisch, aber viele Vorfälle beruhen auf vorhersehbaren Fehlern. Behandle ein JWT wie Bargeld: wer es hat, kann es oft ausgeben.
Wenn ein Token Tage oder Wochen gültig ist, ermöglicht ein Leak dem Angreifer das gesamte Fenster. Bevorzuge kurzlebige Access Tokens (Minuten) und erneuere sie über sichere Mechanismen. "Remember me"‑Funktionen sollten über Refresh Tokens und serverseitige Kontrollen realisiert werden.
Allein eine gültige Signatur reicht nicht. Prüfe iss und aud und validiere zeitbasierte Claims wie exp und nbf.
Decodieren ist keine Verifikation. Verifiziere immer die Signatur serverseitig und setze Berechtigungen serverseitig durch.
Vermeide, JWTs in Query‑Parametern zu übergeben. Sie können so in Browser‑History, Server‑Logs, Analyse‑Tools und Referrer‑Headern landen.
Verwende stattdessen Authorization: Bearer ....
Geh davon aus, dass Schlüssel und Tokens leakieren können. Rotere Signierschlüssel, nutze kid für reibungslose Rotation und habe eine Widerrufsstrategie (kurze Abläufe + Möglichkeit, Konten/Sessions zu deaktivieren). Für Speicherhinweise siehe /blog/where-to-store-jwts-safely.
JWTs sind nützlich, aber nicht automatisch die beste Wahl. Die zentrale Frage ist, ob du von einem selbstenthaltenden Token profitierst, das ohne Datenbank‑Lookup pro Request verifiziert werden kann.
Für traditionelle serverseitig gerenderte Web‑Apps, bei denen einfache Invalidierung wichtig ist, sind serverseitige Sessions mit HttpOnly Cookies oft der einfachere, sicherere Default.
Wähle JWT, wenn du stateless Verifikation über Services brauchst und Tokens kurzlebig halten kannst. Vermeide JWT, wenn du sofortige Widerrufbarkeit brauchst, sensible Daten im Token transportieren müsstest oder du problemlos Session‑Cookies verwenden kannst.
Verifiziere mit dem richtigen Schlüssel und erwartetem Algorithmus. Lehne ungültige Signaturen ohne Ausnahme ab.
exp (Expiration)Stelle sicher, dass das Token nicht abgelaufen ist.
nbf (Not Before)Wenn vorhanden, stelle sicher, dass das Token nicht zu früh verwendet wird.
aud (Audience)Bestätige, dass das Token für deine API/Service gedacht ist.
iss (Issuer)Bestätige, dass das Token vom erwarteten Issuer stammt.
Validiere das Token‑Format, erzwinge maximale Größe und lehne unerwartete Claim‑Typen ab, um Randfälle zu reduzieren.
HS256 (symmetrischer Schlüssel): ein gemeinsames Secret signiert und verifiziert.
: privater Schlüssel signiert; öffentlicher Schlüssel verifiziert.
Faustregel: Wenn mehr als ein unabhängiges System Tokens verifizieren muss (oder du jedem Verifizierer nicht vollständig vertraust), bevorzuge RS256/ES256.
iss, aud, eine Nutzer‑ID nur wenn Richtlinie es erlaubt).Ist JWT verschlüsselt?
Nicht standardmäßig. Die meisten JWTs sind signiert, nicht verschlüsselt, d. h. die Inhalte sind für jeden mit dem Token lesbar. Verwende JWE oder lagere sensible Daten serverseitig.
Kann ich ein JWT widerrufen?
Nicht leicht, wenn du ausschließlich auf selbstenthaltende Access Tokens setzt. Gängige Ansätze sind kurzlebige Access Tokens, Deny‑Lists für Hochrisiko‑Ereignisse oder Refresh Tokens mit Rotation.
Wie lange sollte exp sein?
So kurz wie möglich, ohne die UX zu sehr zu beeinträchtigen. Viele APIs nutzen Minuten für Access Tokens und koppeln längere Sessions an Refresh Tokens.
Wenn du JWT‑Auth in einer neuen API oder SPA implementierst, ist viel Arbeit repetitiv: Middleware verkabeln, iss/aud/exp validieren, Cookie‑Flags setzen und Token‑Handhabung aus Logs fernhalten.
Mit Koder.ai kannst du eine Web‑App (React), Backend‑Services (Go + PostgreSQL) oder eine Flutter‑Mobile‑App per Chat‑gesteuertem Workflow entwickeln—dann im Planungsmodus iterieren, Snapshots und Rollbacks nutzen und den Quellcode exportieren, wenn du bereit bist. Das beschleunigt die Entwicklung von JWT‑basierten Auth‑Flows und hilft, Verifikationslogik, Key‑Rotation‑Strategie und Deployment‑/Hosting‑Einstellungen (inkl. Custom Domains) kontrolliert zu handhaben.
Ein JWT (JSON Web Token) ist eine kompakte, URL-sichere Zeichenkette, die Claims (Datenfelder) trägt und vom Server verifiziert werden kann. Häufig wird es bei API-Anfragen gesendet via:
Authorization: Bearer <token>Die zentrale Idee: Der Server kann die Integrität des Tokens (über die Signatur) prüfen, ohne für jede Anfrage eine serverseitige Session zu speichern.
Session-basierte Authentifizierung speichert in der Regel Zustand auf dem Server (eine Session‑Datensatz, referenziert durch ein Cookie/eine Session-ID). Bei JWT-basierter Authentifizierung legt der Client bei jeder Anfrage ein signiertes Token vor, das die API prüft.
JWTs sind bei APIs und Multi‑Service‑Architekturen beliebt, weil die Verifikation lokal stattfinden kann und die Notwendigkeit geteilter Session‑Speicher reduziert. „Stateless“ bedeutet nicht, dass es keine serverseitigen Prüfungen gibt: Revocation‑Listen, Benutzerstatus oder Key‑Rotation werden oft zusätzlich geprüft.
Ein JWT besteht aus drei Base64URL-kodierten Teilen, durch Punkte getrennt:
header.payload.signatureDer Header beschreibt, wie unterschrieben wurde, der Payload enthält Claims (z. B. sub, exp, aud) und die Signatur ermöglicht es dem Server, Manipulationen zu erkennen.
Nein. Standard‑JWTs sind in der Regel signiert, nicht verschlüsselt.
Wenn Vertraulichkeit nötig ist, nutze JWE (verschlüsselte Tokens) oder lagere sensible Daten serverseitig und setze nur eine Referenz in das JWT.
Die Signatur erlaubt dem Server zu prüfen, dass das Token nicht verändert wurde und von einem Signierer mit dem Schlüssel stammt.
Sie garantiert nicht:
exp)Behandle das Token wie ein Credential: wenn es geleakt wird, kann es meist bis zum Ablaufzeitpunkt wiederverwendet werden.
alg teilt dem Prüfer mit, welcher Algorithmus verwendet wurde (z. B. HS256 vs RS256). kid ist ein Key Identifier, um beim Schlüsselwechsel den richtigen Verifikationsschlüssel auszuwählen.
Sicherheitsregeln auf einen Blick:
Beginne mit den standardisierten (registered) Claims und halte eigene Claims minimal.
Gängige registrierte Claims:
JWT ist ein Token‑Format; OAuth 2.0 und OpenID Connect sind Protokolle.
Typische Zuordnung:
Für Browser‑Apps sind gängige Optionen:
Wenn du Cookies nutzt, setze:
Mindestens prüfe:
exp (nicht abgelaufen)iss (erwarteter Issuer)aud (für deine API gedacht)nbf (falls vorhanden)Praktische Ergänzungen:
iss (issuer): wer das Token erstellt hatsub (subject): worum es geht (oft eine Nutzer‑ID)aud (audience): für wen das Token gedacht ist (z. B. eine bestimmte API)exp (expiration time): wann das Token nicht mehr akzeptiert werden darfiat (issued at): wann das Token erstellt wurdenbf (not before): ab wann das Token gültig istalg‑Werte.alg: "none".kid‑Lookup‑Verhalten, die zu falscher Schlüsselwahl führen können.iss (Issuer) — wer das Token erstellt hatsub (Subject) — für wen das Token ist (häufig die Nutzer-ID)aud (Audience) — für wen das Token gedacht istexp (Expiration) — Ablaufzeitiat (Issued At) — Ausstellungszeitnbf (Not Before) — token nicht vor dieser Zeit akzeptierenVermeide Geheimnisse oder sensible persönliche Daten im Payload, da dieser lesbar ist, falls das Token offengelegt wird.
Wichtig: Verwende kein ID Token, um eine API aufzurufen — das ID Token ist für den Client bestimmt.
HttpOnlySecure (nur HTTPS)SameSite=Lax oder SameSite=Strict (bei manchen Cross‑Site‑Flows SameSite=None; Secure)Erwäge zusätzlich CSRF‑Tokens für zustandsändernde Requests. Unabhängig von der Wahl: halte Access Tokens kurzlebig und minimiere Berechtigungen.