Was ist JWT? Ein klarer Leitfaden zu JSON Web Tokens

JWT einfach erklärt

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.

Warum überhaupt ein Token verwenden?

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:

• gut über mehrere Dienste hinweg funktioniert (API‑Gateways, Microservices)
• zu mobilen Apps und Single‑Page‑Apps (SPAs) passt, die direkt APIs aufrufen
• den Bedarf an gemeinsamem Session‑Speicher zwischen Servern reduziert

Wichtige Nuance: “stateless” heißt nicht “keine serverseitigen Prüfungen”. Viele reale Systeme validieren Tokens zusätzlich gegen Benutzerstatus, rotierende Schlüssel oder Widerrufsmechanismen.

Authentifizierung vs. Autorisierung (einfach erklärt)

• Authentifizierung beantwortet: Wer bist du? (Du meldest dich an und beweist deine Identität.)
• Autorisierung beantwortet: Was darfst du tun? (Du kannst Rechnungen lesen, Projekte bearbeiten, Admin‑Seiten aufrufen etc.)

JWTs tragen häufig den Beleg der Authentifizierung (du bist angemeldet) und einfache Autorisierungs‑Hinweise (Rollen, Berechtigungen, Scopes) — deine Serverlogik muss Autorisierungsregeln trotzdem durchsetzen.

Wo treten JWTs auf?

JWTs werden oft als Access Tokens verwendet in:

• Web‑APIs
• SPAs
• mobilen Apps
• Systemen mit OAuth 2.0 oder OpenID Connect (OIDC)

JWT‑Aufbau: Header, Payload und Signature

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…

1) Header

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 Signaturalgorithmus
• kid: Key Identifier, damit der Verifizierer beim Schlüsselwechsel den richtigen Schlüssel auswählen kann

Sicherheits‑Hinweis: Vertraue dem Header nicht blind. Erzwinge eine Allowlist der Algorithmen, die du tatsächlich verwendest, und akzeptiere nicht alg: "none".

2) Payload

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.

3) Signatur

Die Signatur wird erzeugt, indem Header + Payload mit einem Schlüssel signiert werden:

• HS256: ein geteilter Secret signiert und verifiziert
• RS256/ES256: ein privater Schlüssel signiert; ein öffentlicher Schlüssel verifiziert

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.

Größenüberlegungen

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.

Payload und Claims: was du speichern kannst — und was nicht

Claims fallen meist in zwei Kategorien: registered (standardisierte Namen) und custom (anwendungsspezifische Felder).

Häufige registered Claims

• iss (issuer): wer das Token erstellt hat
• sub (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 darf
• iat (issued at): wann das Token erstellt wurde
• nbf (not before): ab wann das Token gültig ist

Custom Claims: möglichst minimal halten

Nimm nur auf, was der empfangende Dienst wirklich braucht, um eine Autorisierungsentscheidung zu treffen.

Gute Beispiele:

• eine stabile interne Nutzer‑ID (user_id)
• eine kleine Menge an Rollen/Berechtigungen (nur wenn du sie aktuell halten kannst)
• eine Mandanten‑/Organisation‑ID in Multi‑Tenant‑Apps

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.

Was du niemals in den JWT‑Payload legen solltest

Da der Payload lesbar ist, solltest du nicht speichern:

• Passwörter, API‑Keys, Refresh Tokens oder andere Geheimwerte
• Zahlungsdaten, Ausweisnummern oder sensible persönliche Daten
• irgendetwas, das du nicht kopiert sehen möchtest (Browser, Proxy, Logs)

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.

Wie die Signatur funktioniert (und was sie garantiert)

Signieren ist nicht Verschlüsseln.

• Signieren ist wie einen Brief versiegeln: man kann ihn lesen, aber man kann prüfen, ob er verändert wurde.
• Verschlüsseln ist wie einen Brief in eine verschlossene Kiste legen: nur mit dem Schlüssel ist er lesbar.

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 vs OAuth, OpenID Connect und Token‑Typen

JWT ist ein Tokenformat. OAuth 2.0 und OpenID Connect (OIDC) sind Protokolle, die beschreiben, wie Apps Tokens anfordern und verwenden.

OAuth 2.0 und Access/Refresh Tokens

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 Token: wird einer API vorgelegt, um Berechtigungen nachzuweisen; kann ein JWT oder ein opaques Token sein
• Refresh Token: länger lebendes Token, um neue Access Tokens zu erhalten

Access Tokens sind typischerweise kurzlebig (Minuten). Kurze Lebenszeiten begrenzen den Schaden, falls ein Token leakiert.

OpenID Connect (OIDC) und ID Tokens

OIDC ergänzt OAuth 2.0 um Authentifizierung und führt das ID Token ein, das gewöhnlich ein JWT ist.

• ID Token: dient der Client‑App zur Bestätigung der Identität des Nutzers
• Access Token: dient der API zur Autorisierung von Requests

Eine wichtige Regel: verwende kein ID Token, um eine API aufzurufen.

Wenn du mehr zu praktischen Flows möchtest, siehe /blog/jwt-authentication-flow.

Üblicher JWT‑Authentifizierungsablauf

Ein typischer Ablauf sieht so aus:

1) Anmeldung

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.

2) Tokenausgabe

Der Server signiert das Token und gibt es an den Client zurück (Web‑App, Mobile‑App oder ein anderer Dienst).

3) API‑Aufrufe

Für geschützte Endpunkte sendet der Client das JWT im Authorization‑Header:

Authorization: Bearer <JWT>

4) Verifikation

Vor der Bearbeitung prüft die API typischerweise:

• Signatur (Integrität + vertrauenswürdiger Aussteller)
• 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).

5) Kurzer Hinweis zur Clock‑Skew

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.

Wo man JWTs sicher speichert

Die Speicheroption beeinflusst, welche Angreifer Tokens stehlen können und wie leicht sie Tokens wiederverwenden.

Browser‑Apps: Memory vs localStorage vs Cookies

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:

• HttpOnly
• Secure (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.

Mobile Apps: sichere OS‑Speicher verwenden

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.

Principle of least privilege

Beschränke, was ein Token darf: nutze minimale Scopes/Claims, halte Access Tokens kurzlebig und vermeide das Einbetten sensibler Daten.

Häufige Sicherheitsfallen bei JWTs

JWTs sind praktisch, aber viele Vorfälle beruhen auf vorhersehbaren Fehlern. Behandle ein JWT wie Bargeld: wer es hat, kann es oft ausgeben.

1) Zu lange Ablaufzeiten

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.

2) Auslassen von Issuer‑ und Audience‑Prüfungen

Allein eine gültige Signatur reicht nicht. Prüfe iss und aud und validiere zeitbasierte Claims wie exp und nbf.

3) Auf decodiertes Payload vertrauen

Decodieren ist keine Verifikation. Verifiziere immer die Signatur serverseitig und setze Berechtigungen serverseitig durch.

4) Algorithmus‑Verwirrung und Schlüssel‑Mixups

• Akzeptiere nicht einfach jeden im Token angegebenen Algorithmus. Nutze eine Allowlist.
• Vermische nicht symmetrische Schlüssel (HS256) mit asymmetrischen (RS256/ES256).
• Reduziere die Blast‑Radius, indem du Schlüssel pro Umgebung trennst und rotierst.

5) Token‑Lecks über URLs, Logs und Referrer

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 ....

6) Keine Key‑Rotation oder Revocation‑Strategie

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.

Wann JWT sinnvoll ist (und wann nicht)

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.

Gute Einsatzfälle für JWT

• Stateless‑APIs in großem Maßstab: lokale Verifikation (Signatur + Expiry) ohne pro‑Request Session‑Lookups
• Mehrere Dienste / Microservices: gemeinsame Verifikationsregeln und öffentliche Schlüssel
• SPAs und mobile Apps: Clients rufen APIs direkt auf
• Kurzlebige Access Tokens: begrenzter Schaden bei Verlust

Wann JWT ungeeignet ist

• Sofortige Widerrufbarkeit ist Pflicht: Sessions sind einfacher, wenn du überall sofort abmelden musst, ohne zusätzliche Infrastruktur
• Du musst sensible Daten mittragen: typische JWTs sind signiert, nicht verschlüsselt
• Langlebige Tokens: sie haben hohen Wert und sind attraktiv für Angreifer

Wann einfache Session‑Cookies besser sind

Für traditionelle serverseitig gerenderte Web‑Apps, bei denen einfache Invalidierung wichtig ist, sind serverseitige Sessions mit HttpOnly Cookies oft der einfachere, sicherere Default.

Kurzcheckliste zur Entscheidung

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.

Praktische Checkliste und FAQs

Verifikations‑Checkliste (bei jeder Prüfung)

1. Signatur ist gültig

Verifiziere mit dem richtigen Schlüssel und erwartetem Algorithmus. Lehne ungültige Signaturen ohne Ausnahme ab.

2. exp (Expiration)

Stelle sicher, dass das Token nicht abgelaufen ist.

3. nbf (Not Before)

Wenn vorhanden, stelle sicher, dass das Token nicht zu früh verwendet wird.

4. aud (Audience)

Bestätige, dass das Token für deine API/Service gedacht ist.

5. iss (Issuer)

Bestätige, dass das Token vom erwarteten Issuer stammt.

6. Sanity‑Checks (empfohlen)

Validiere das Token‑Format, erzwinge maximale Größe und lehne unerwartete Claim‑Typen ab, um Randfälle zu reduzieren.

HS256 vs RS256/ES256 wählen

• HS256 (symmetrischer Schlüssel): ein gemeinsames Secret signiert und verifiziert.

  • Gut für: eine einzelne App/API, die von einem Team betrieben wird.
  • Achtung: Jeder Verifizierer mit dem Secret kann auch Tokens ausstellen.

• RS256 / ES256 (asymmetrische Schlüssel): privater Schlüssel signiert; öffentlicher Schlüssel verifiziert.

  • Gut für: mehrere Dienste, die Tokens verifizieren; öffentliche Schlüssel können verteilt werden, ohne Signierrechte zu geben.
  • Operativ: Rotation ist oft sicherer, weil nur der Signierer den privaten Schlüssel besitzt.

Faustregel: Wenn mehr als ein unabhängiges System Tokens verifizieren muss (oder du jedem Verifizierer nicht vollständig vertraust), bevorzuge RS256/ES256.

Monitoring und Logging (ohne Tokens zu leaken)

• Logge keine rohen Tokens (Header, Cookies, Query‑Strings).
• Wenn du Korrelation brauchst, logge einen Token‑Fingerprint (z. B. einen Hash) oder sichere Metadaten (iss, aud, eine Nutzer‑ID nur wenn Richtlinie es erlaubt).
• Achte auf Anomalien: Signatur‑Fehler, Spitzen bei abgelaufenen Tokens, ungewöhnliche Audiences/Issuers und verdächtige Refresh‑Muster.

FAQs

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.

JWT‑geschützte Apps schneller bauen mit Koder.ai

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.