Die zwei Tokens existieren, um einen direkten Konflikt zu lösen: ein Access Token muss bei jedem Request gesendet werden (es ist also stark exponiert), zugleich willst du aber Sessions, die lange dauern, ohne häufige Logins zu erzwingen. Beides lässt sich in einem einzigen Token nicht sicher haben — also teilst du die Aufgabe auf.
Authorization-Header gesendet. Da es ständig übertragen wird, ist ein Leck wahrscheinlich; es kurz zu halten bedeutet, dass ein gestohlenes fast sofort abläuft.Login ──▶ access (15m) + refresh (30d)
Every API call ──▶ send access
Access expired ──▶ send refresh ──▶ new access (+ rotated refresh)
| Ein langlebiges Access Token | Access + Refresh | |
|---|---|---|
| Exponierung | Bei jedem Request gesendet, lebt lange → großes Diebstahlfenster | Access kurzlebig; Refresh selten gesendet |
| Widerruf | Schwer (zustandsloses JWT lässt sich nicht zurückziehen) | Refresh Token widerrufen; Access stirbt binnen Minuten |
| UX | Häufiges erneutes Login, wenn kurz | Bleibt eingeloggt ohne erneute Eingabe der Zugangsdaten |
| Schadensradius eines Lecks | Groß | Klein (Access läuft schnell ab) |
httpOnly-Cookie gespeichert, außer Reichweite von XSS.Dies ist das moderne Standard-Auth-Design, und Interviewer fragen es, um zu sehen, ob du das Warum verstehst, nicht nur das Wie. Die zentrale Erkenntnis ist der Kompromiss: Zustandslosigkeit und kurze Exponierung (Access) versus lange Sessions und Widerrufbarkeit (Refresh). Es falsch zu machen — ein langlebiges Access Token, keine Rotation, Refresh in localStorage gespeichert — verwandelt ein einziges geleaktes Token in eine langlebige Kontokompromittierung. Die Aufteilung zu benennen und was dir jedes Token bringt, ist das, was von einem sicherheitsbewussten Entwickler erwartet wird.
Eine Sammlung von IT-Interviewfragen mit ausführlichen Antworten — vom Junior bis zum Senior.
Spenden