Wie arbeiten Access Tokens und Refresh Tokens zusammen?

Question

IT Interview Practice · Accepted Answer

Die zwei Tokens folgen einem einfachen Lebenszyklus: ein **kurzlebiges Access Token** autorisiert jeden API-Aufruf, und ein **langlebiges Refresh Token** prägt still neue Access Tokens, wenn sie ablaufen — sodass der Nutzer eingeloggt bleibt, ohne seine Zugangsdaten erneut einzugeben.

## Der Ablauf

```
┌─────────┐  1. login (user + pass)   ┌────────────┐
│ Client  │ ────────────────────────▶ │ Auth server│
│         │ ◀──── access + refresh ─── │            │
└─────────┘                            └────────────┘
     │  2. API call: Authorization: Bearer <access>
     ▼
┌────────────┐  verify signature + exp   (no DB lookup)
│ Resource   │ ──── 200 OK ────▶ (access still valid)
│ API        │ ──── 401 ───────▶ (access expired)
└────────────┘
     │  3. on 401: POST /token { refresh }
     ▼
┌────────────┐  verify + rotate
│ Auth server│ ──── new access (+ new refresh) ────▶ retry the call
└────────────┘
```

1. **Login** — der Nutzer authentifiziert sich einmal; der Server gibt ein **Access Token** (kurze TTL) und ein **Refresh Token** (lange TTL) zurück.
2. **Zugriff auf APIs** — der Client sendet das Access Token bei jedem Request in `Authorization: Bearer …`. Das API verifiziert es zustandslos (Signatur + `exp`) und antwortet — kein Session-Store nötig.
3. **Refresh bei Ablauf** — wenn das API `401` zurückgibt (oder der Client sieht, dass `exp` nah ist), POSTet der Client das **Refresh Token** an den `/token`-Endpoint des Auth-Servers und erhält ein frisches Access Token, dann wiederholt er den ursprünglichen Request. Der Nutzer bemerkt nichts.
4. **Logout / Widerruf** — der Server löscht das Refresh Token oder setzt es auf eine Denylist; der nächste Refresh schlägt fehl und die Session endet (das aktuelle Access Token stirbt trotzdem von selbst binnen Minuten).

```js
// Client-Interceptor: bei 401 einmal refreshen, dann erneut versuchen.
async function apiFetch(url, opts = {}) {
  let res = await fetch(url, withAuth(opts, accessToken));
  if (res.status === 401) {
    accessToken = await refreshAccessToken(refreshToken); // POST /token
    res = await fetch(url, withAuth(opts, accessToken));   // erneut versuchen
  }
  return res;
}
```

## Refresh-Token-Rotation

Best Practice ist **Rotation**: jeder Refresh-Aufruf gibt ein *neues* Refresh Token zurück und macht das alte ungültig. Wird ein altes (bereits genutztes) Refresh Token erneut vorgelegt, signalisiert das Diebstahl — der Server widerruft die gesamte Token-Familie und erzwingt ein erneutes Login. Das begrenzt den Schaden eines gestohlenen Refresh Tokens.

## Speicherung

- **Refresh Token** → `httpOnly`-, `Secure`-, `SameSite`-Cookie, damit JavaScript (und somit XSS) es nicht lesen kann.
- **Access Token** → im Speicher des Clients gehalten; die kurze Lebensdauer begrenzt die Exponierung.
- Lege keines von beiden in `localStorage`, wenn du es vermeiden kannst — es ist von jedem injizierten Skript lesbar.

## Warum es wichtig ist

Dieser Ablauf ist das Rückgrat der Session-Verwaltung in modernen SPAs, Mobile-Apps und APIs, daher erwarten Interviewer, dass du ihn von Anfang bis Ende nachvollziehst: beide beim Login ausstellen, mit dem Access Token autorisieren, bei Ablauf transparent refreshen und zur Sicherheit rotieren + widerrufen. Die Details richtig zu machen — zustandslose Verifizierung, Refresh nur am Token-Endpoint, Rotation mit Wiederverwendungserkennung und `httpOnly`-Speicherung — ist der Unterschied zwischen einer reibungslosen, sicheren Session und einer, bei der ein einziges gestohlenes Token eine langlebige Kontoübernahme bedeutet.

Der Ablauf

Refresh-Token-Rotation

Speicherung

Warum es wichtig ist

Ähnliche Fragen