Wie verwaltest du Session- und Token-Lebensdauern (Access vs. Refresh, Rotation)?
Kurzantwort
Halte Access-Tokens kurzlebig (Minuten), damit ein gestohlenes schnell abläuft, und nutze langlebigere Refresh-Tokens, um neue Access-Tokens zu erhalten, ohne den Benutzer erneut aufzufordern. Rotiere Refresh-Tokens bei jeder Verwendung und erkenne die Wiederverwendung eines verbrauchten Tokens als Diebstahlsignal, das die Kette widerruft. Das Ziel ist, das Begrenzen des Fensters eines kompromittierten Tokens gegen das Vermeiden ständiger erneuter Anmeldungen abzuwägen.
Tokens und Sessions sind Inhaber-Credentials: Wer eines hält, wird als der Benutzer behandelt. Ihre Lebensdauer ist also ein direkter Sicherheitshebel, und das Interview will hören, dass du den Trade-off verstehst.
Access- vs. Refresh-Tokens
- Access-Token — wird bei jedem API-Aufruf präsentiert, oft ein zustandsloses JWT. Mach es kurzlebig (typischerweise 5–15 Minuten). Wird es gestohlen, ist das Fenster des Angreifers klein, und weil es zustandslos ist, kannst du es üblicherweise nicht mitten in der Lebensdauer widerrufen — kurze Ablaufzeit ist die Gegenmaßnahme.
- Refresh-Token — langlebiger, sorgfältiger verwahrt, nur genutzt, um neue Access-Tokens zu prägen, wenn das alte abläuft. Das hält den Benutzer angemeldet, ohne erneut aufzufordern, während das hochwertige Geheimnis selten und über den Back-Channel ausgetauscht wird.
Refresh-Token-Rotation
Best Practice (RFC 9700) sind einmalig verwendbare Refresh-Tokens mit Rotation: Jeder Refresh gibt ein neues Refresh-Token zurück und macht das alte ungültig. Der Hauptvorteil ist Diebstahlerkennung — wird ein zuvor verwendetes (nun ungültiges) Refresh-Token erneut präsentiert, bedeutet das, dass zwei Parteien Kopien halten. Der Server behandelt es als Kompromittierung und widerruft die gesamte Token-Familie, womit der Benutzer überall abgemeldet wird.
Sessions: Idle- vs. Absolute-Timeouts
Für serverseitige Sessions kombiniere ein Idle-Timeout (Ablauf nach Inaktivität) mit einem Absolute-Timeout (harte Obergrenze unabhängig von Aktivität). Binde Sessions an ein sicheres HttpOnly-, SameSite-Cookie und regeneriere die Session-ID bei Privilegienwechsel (z. B. nach dem Login), um Fixation zu vereiteln.
Speicher-Fallstricke
In Browsern bevorzuge HttpOnly-Cookies gegenüber localStorage, das von jeder XSS-Payload lesbar ist. Biete immer explizites Logout und serverseitigen Widerruf für das langlebige Credential.
Worauf Interviewer achten: Du stellst kurze Access- gegen längere Refresh-Lebensdauern gegenüber, kannst erklären, wie Rotation die Refresh-Wiederverwendung in einen Diebstahlalarm verwandelt, und weißt, dass zustandslose JWTs Widerrufbarkeit gegen kurze Ablaufzeit eintauschen.
Wahrscheinliche Anschlussfragen
- Wie erkennt Refresh-Token-Rotation ein gestohlenes Token?
- Warum kannst du ein zustandsloses JWT-Access-Token nicht einfach mitten in der Lebensdauer widerrufen?
- Wo sollten Tokens in einem Browser gespeichert werden, und warum nicht im localStorage?