JWT (JSON Web Token)

Einfach erklärt

Ein JWT (JSON Web Token) ist ein signierter Token, der Informationen enthält und bei API-Requests zur Authentifizierung oder Autorisierung mitgesendet werden kann. Der Server kann den Token oft prüfen, ohne eine klassische Session-Datenbank abzufragen.

Der Ablauf:

1. Login
   User → [email + password] → Server
   Server → [JWT] → User

2. API-Requests
   User → [Request + JWT im Header] → Server
   Server prüft JWT-Signatur
   Server → [Response] → User

JWT-Struktur:

base64url(header).
base64url(payload).
base64url(signature)

Header.Payload.Signature

Teil	Inhalt	Beispiel
Header	Algorithmus, Typ	{"alg": "HS256", "typ": "JWT"}
Payload	Claims (Daten)	{"sub": "user-id", "exp": expiry_timestamp}
Signature	Signatur	HMAC-SHA256(header + payload, secret)

Technischer Deep Dive

JWT erstellen

Node.js Beispiel:

const jwt = require('jsonwebtoken');

const token = jwt.sign(
  {
    sub: userId,
    role: userRole,
    iat: Math.floor(Date.now() / 1000),
    exp: Math.floor(Date.now() / 1000) + accessTokenLifetime
  },
  process.env.JWT_SECRET,
  { algorithm: 'HS256' }
);

JWT verifizieren

try {
  const decoded = jwt.verify(token, process.env.JWT_SECRET);
  console.log(decoded);
  // { sub: userId, role: userRole, ... }
} catch (err) {
  if (err.name === 'TokenExpiredError') {
    // Token abgelaufen
  } else if (err.name === 'JsonWebTokenError') {
    // Ungültige Signatur
  }
}

Standard Claims

Claim	Name	Beschreibung
iss	Issuer	Wer hat den Token ausgestellt?
sub	Subject	Für wen ist der Token? (User ID)
aud	Audience	Für welchen Service?
exp	Expiration	Wann läuft er ab?
iat	Issued At	Wann wurde er ausgestellt?
nbf	Not Before	Ab wann gültig?
jti	JWT ID	Eindeutige Token-ID

Access + Refresh Token Pattern

Login:
Server → kurzlebiges Access Token + länger geschütztes Refresh Token

API-Request:
Client → Access Token → Server
         ↓
      Abgelaufen?
         ↓
Client → Refresh Token → Server
Server → Neuer Access Token → Client

Warum zwei Tokens?

• Access Token: Kurz, oft verwendet, bei Leak begrenzt Schaden
• Refresh Token: Lang, selten verwendet, sicher gespeichert

Sicherheits-Best-Practices

Do:

• TLS für Transportverschlüsselung verwenden
• starke Schlüssel und sichere Key-Verwaltung nutzen
• Laufzeiten risikobasiert begrenzen
• Algorithmus explizit prüfen
• Audience und Issuer validieren

Don’t:

• sensible Daten im Payload vermeiden
• none-Algorithmus oder unerwartete Algorithmen nicht akzeptieren
• Speicherort im Client gegen XSS/CSRF-Risiken abwägen
• überlange Laufzeiten vermeiden
• schwache oder hardcodierte Secrets vermeiden

JWT vs. Session

Aspekt	JWT	Session
Speicherort	Client	Server
Skalierung	oft einfacher stateless möglich	benötigt Session Store oder Replikation
Invalidierung	ohne Zusatzmechanismen schwieriger	zentral oft einfacher
Größe	größer, weil Claims enthalten sein können	klein, meist nur ID
Microservices	häufig gut nutzbar	abhängig von Session-Architektur

Algorithmen

Algorithmus	Typ	Empfehlung
HS256	Symmetric (HMAC)	passend bei sicher geteilter Secret-Verwaltung
RS256	Asymmetric (RSA)	häufig bei verteilter Verifikation
ES256	Asymmetric (ECDSA)	kompaktere Signaturen möglich
none	keine Signatur	in produktiven Auth-Flows nicht akzeptieren