Wie funktioniert ein JSON Web Token (JWT)?

Question

IT Interview Practice · Accepted Answer

Ein **JSON Web Token (JWT)** ist ein kompaktes, URL-sicheres, in sich geschlossenes Token, das Claims über einen Benutzer trägt. Der Server signiert es einmal; danach kann er das Token bei jeder Anfrage **verifizieren**, ohne einen Datenbank-Lookup — genau das macht JWT-basierte Auth *stateless*.

## Struktur: drei base64url-Teile

Ein JWT ist `header.payload.signature`, drei base64url-kodierte Segmente, verbunden durch Punkte:

```
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9   ← header
.eyJzdWIiOiIxMjMiLCJleHAiOjE3MDB9      ← payload (claims)
.dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1    ← signature
```

- **Header** — der Signieralgorithmus, z. B. `{ "alg": "HS256", "typ": "JWT" }`.
- **Payload** — die **Claims**: Standard-Claims wie `sub` (Subject/User-ID), `exp` (Ablauf), `iat` (issued-at), `iss` (Issuer), plus beliebige benutzerdefinierte Felder (`role`, `email`).
- **Signature** — berechnet über Header und Payload mit einem Secret oder einem privaten Schlüssel.

> Die Payload ist **kodiert, nicht verschlüsselt**. Jeder kann sie base64-dekodieren und lesen, also lege niemals Passwörter oder Geheimnisse in ein JWT.

## Wie Signieren und Verifizieren funktionieren

```
signature = HMAC-SHA256(
  base64url(header) + "." + base64url(payload),
  secret
)
```

- **HS256** (symmetrisch): dasselbe Secret signiert und verifiziert. Einfach, aber jeder Verifizierer muss das Secret halten.
- **RS256** (asymmetrisch): ein **privater Schlüssel** signiert, ein **öffentlicher Schlüssel** verifiziert. Der Auth-Server behält den privaten Schlüssel; andere Dienste verifizieren mit dem öffentlichen Schlüssel und können niemals Tokens ausstellen.

Bei jeder Anfrage berechnet der Server die Signatur über den empfangenen Header+Payload neu und vergleicht sie. Stimmen sie überein und liegt `exp` in der Zukunft, wird dem Token vertraut — kein Session-Store nötig.

```js
const jwt = require("jsonwebtoken");

const token = jwt.sign({ sub: "123", role: "admin" }, SECRET, {
  expiresIn: "15m",
});

try {
  const claims = jwt.verify(token, SECRET); // wirft, wenn manipuliert oder abgelaufen
  // claims.sub === "123"
} catch (e) {
  // ablehnen: ungültig oder abgelaufen
}
```

## Der schwierige Teil: Widerruf (revocation)

Weil die Verifizierung stateless ist, **kannst du** ein Token nicht vor seinem Ablauf ungültig machen, indem du es serverseitig einfach „löschst“. Gängige Gegenmaßnahmen:

- Halte Access Tokens **kurzlebig** (5–15 Min.) und paare sie mit einem länger lebenden **Refresh Token**.
- Führe eine kleine **Denylist** widerrufener Token-IDs (`jti`) für Logout/Kompromittierung — das führt ein wenig State wieder ein.
- Rotiere die Signierschlüssel.

## Speicher-Trade-offs

| Speicher | Vorteil | Nachteil |
|---|---|---|
| `httpOnly`-Cookie | Für JS nicht lesbar (XSS-sicherer) | Braucht CSRF-Schutz |
| `localStorage` | Einfach, kein CSRF | Für XSS exponiert |

## Warum es wichtig ist

JWTs treiben stateless Authentifizierung über APIs, Microservices und SPAs hinweg an — ein Dienst kann einer Anfrage allein durch das Verifizieren einer Signatur vertrauen, ohne einen gemeinsamen Session-Store. Doch genau diese Statelessness ist die klassische Interview-Falle: Tokens lassen sich nicht leicht widerrufen, die Payload ist lesbar, und `alg`-Verwirrung oder eine fehlende Ablaufprüfung sind echte Schwachstellen. Genau zu wissen, was die Signatur schützt und was nicht, ist entscheidend, um JWTs sicher zu verwenden.

Speicher	Vorteil	Nachteil
`httpOnly`-Cookie	Für JS nicht lesbar (XSS-sicherer)	Braucht CSRF-Schutz
`localStorage`	Einfach, kein CSRF	Für XSS exponiert

Struktur: drei base64url-Teile

Wie Signieren und Verifizieren funktionieren

Der schwierige Teil: Widerruf (revocation)

Speicher-Trade-offs

Warum es wichtig ist

Ähnliche Fragen