JWT

Enthält Metadaten über den Token: den Signaturalgorithmus (alg) und den Token-Typ (typ). Die Algorithmuswahl im Header beeinflusst die gesamte Sicherheit des Tokens — ein schwacher oder fehlender Algorithmus macht die Signatur wertlos.

{
  "alg": "HS256",
  "typ": "JWT"
}

Enthält die Claims: Aussagen über den Benutzer und zusätzliche Metadaten. Die Payload-Daten sind NICHT verschlüsselt, nur signiert. Das bedeutet, dass jeder, der den Token abfängt, die Payload lesen kann — sensible Daten wie Passwörter dürfen daher niemals in der Payload gespeichert werden.

{
  "sub": "user_123",
  "role": "admin",
  "exp": 1717200000
}

Eine kryptographische Signatur über den kodierten Header und Payload. Die Überprüfung dieser Signatur stellt sicher, dass der Token nicht manipuliert wurde. Der geheime Schlüssel (bei HMAC) bzw. der private Schlüssel (bei RSA/ECDSA) ist niemals im Token selbst enthalten und muss serverseitig sicher aufbewahrt werden.

HMACSHA256(
  base64url(header) + "." +
  base64url(payload),
  secret
)

Verwendet einen gemeinsamen geheimen Schlüssel zum Signieren und Verifizieren. Einfach zu implementieren, aber der Schlüssel muss sicher an alle verifizierenden Parteien übertragen und dort geschützt gespeichert werden.

Verwendet einen privaten Schlüssel zum Signieren und einen öffentlichen Schlüssel zum Verifizieren. Der private Schlüssel verbleibt ausschließlich auf dem Auth-Server, während der öffentliche Schlüssel bedenkenlos an alle Verifier weitergegeben werden kann — beispielsweise über einen JWKS-Endpunkt.

Wie RSA, aber mit kleineren Schlüsseln und schnellerer Signierung. Ein ECDSA-Schlüsselpaar mit 256 Bit bietet eine vergleichbare Sicherheit wie ein 3072-Bit-RSA-Schlüssel und ist damit besonders effizient auf Geräten mit begrenzten Ressourcen.

Keine Signatur. Ein Token mit alg:none hat keine Integritätsgarantie und kann von jedem gefälscht werden.

Einige Bibliotheken akzeptieren Tokens mit alg:none. Ein Angreifer kann die Payload ändern und alg auf none setzen, um beliebige JWTs zu fälschen. Den erlaubten Algorithmus immer explizit im Verifier festlegen — nie den Wert aus dem Token-Header ungeprüft übernehmen.

Wenn eine Bibliothek RS256 verifizieren soll, aber HS256 akzeptiert, kann ein Angreifer einen Token mit dem öffentlichen Schlüssel als HMAC-Geheimnis signieren. Den erwarteten Algorithmus immer explizit pinnen — niemals dynamisch aus dem Token-Header lesen.

Ein JWT ohne exp-Claim oder Code, der exp nicht prüft, ermöglicht die unbegrenzte Verwendung von Tokens. Abgelaufene Tokens können auch nach dem Abmelden oder Sperren eines Kontos weiterhin gültig sein, was ein erhebliches Sicherheitsrisiko darstellt.

JWT-Payloads sind Base64-kodiert, nicht verschlüsselt. Niemals Passwörter oder andere Geheimnisse in JWT-Claims speichern. Wer einen Token abfängt — etwa durch einen Man-in-the-Middle-Angriff oder XSS — kann die gesamte Payload im Klartext lesen.

HMAC-signierte JWTs mit kurzen oder vorhersehbaren Geheimnissen können offline per Brute-Force geknackt werden. Kryptographisch zufällige Geheimnisse mit mindestens 256 Bit verwenden — kurze oder sprechende Passwörter sind absolut ungeeignet.

JWTs ohne Signaturprüfung zu akzeptieren vertraut der Payload vollständig. Dies ist ein kritischer Fehler, der es jedem Benutzer ermöglicht, beliebige Claims zu erfinden. Die Signatur immer vor dem Vertrauen in Claims verifizieren.

Standard-JWTs (JWS — JSON Web Signature) sind signiert, aber NICHT verschlüsselt. Die Payload ist Base64url-kodiert, was trivial umkehrbar ist. Wer einen JWT abfängt, kann seinen Inhalt sofort lesen. JWE (JSON Web Encryption) bietet echte Verschlüsselung, ist jedoch deutlich seltener verbreitet und erfordert zusätzliche Schlüsselverwaltung.

Zugriffstoken sollten kurzlebig sein: 5–60 Minuten ist typisch. Langlebige Tokens sind gefährlich, weil sie ohne eine Token-Sperrliste nicht widerrufen werden können. Refresh-Token (länger gültig, sicher gespeichert) für den Erhalt neuer Zugriffstoken verwenden. Je kürzer die Zugriffstoken-Lebensdauer, desto geringer ist das Schadenspotenzial eines gestohlenen Tokens.

HttpOnly-Cookies sind die sicherste Option — sie sind für JavaScript nicht zugänglich und verhindern XSS-Diebstahl. localStorage ist anfällig für XSS-Angriffe, vermeidet aber CSRF. Memory (JavaScript-Variable) ist am sichersten, überlebt jedoch keinen Seitenneuladen. Für die meisten Anwendungen bieten HttpOnly-Cookies mit SameSite=Strict den besten Kompromiss aus Sicherheit und Benutzerfreundlichkeit.

Nicht ohne serverseitigen Zustand. Die zustandslose Natur von JWTs bedeutet, dass der Server sie nicht ungültig machen kann. Lösungen: kurze Ablaufzeiten, eine Token-Sperrliste (Redis), rotierende Refresh-Token oder der Wechsel zu opaken Session-Tokens für sicherheitskritische Vorgänge. Ein hybrides Modell mit kurzen Zugriffstoken und einer Sperrliste für Refresh-Token ist in der Praxis weit verbreitet.

Session-Cookies speichern eine zufällige Session-ID; der Server sucht die Session-Daten in einer Datenbank. JWTs sind eigenständig — der Server validiert die Signatur ohne Datenbankabfrage. JWTs skalieren besser auf mehrere Server, können aber ohne zusätzliche Infrastruktur nicht widerrufen werden. Session-Cookies eignen sich besser für Anwendungen, bei denen sofortiger Widerruf (z.B. nach einem Passwort-Reset) unbedingt erforderlich ist.

Das Minimum: sub (Benutzer-ID), exp (Ablauf) und iat (ausgestellt am). iss (Aussteller) für Multi-Service-Setups hinzufügen. Payloads klein halten — JWTs werden bei jeder Anfrage übertragen. Keine sensiblen Daten oder große Profilobjekte einschließen. Rollen und Berechtigungen können aufgenommen werden, sollten aber granular und auf das Notwendige beschränkt bleiben.

RS256 (asymmetrisch) ist für die meisten Produktionssysteme besser, da nur der Auth-Server den privaten Schlüssel benötigt. Mehrere Dienste können Tokens mit dem öffentlichen Schlüssel verifizieren, ohne ein gemeinsames Geheimnis zu teilen. HS256 ist einfacher, erfordert aber, dass alle Verifier das gemeinsame Geheimnis kennen — bei Microservices ein erhebliches Risiko, da ein kompromittierter Dienst das Geheimnis preisgeben kann.

PKCE ist eine Erweiterung des OAuth2-Autorisierungscode-Flows, die Autorisierungscode-Abfangangriffe verhindert. Es ist für öffentliche Clients (SPAs, mobile Apps) erforderlich, die ein Client-Geheimnis nicht sicher speichern können.