How do you manage session and token lifetimes (access vs refresh, rotation)?

Tokens and sessions are bearer credentials: whoever holds one is treated as the user. So their lifetime is a direct security lever, and the interview wants to hear that you understand the trade-off.

Access vs refresh tokens

• Access token — presented on every API call, often a stateless JWT. Make it short-lived (typically 5–15 minutes). If it's stolen, the attacker's window is small, and because it's stateless you usually can't revoke it mid-life — short expiry is the mitigation.
• Refresh token — longer-lived, held more carefully, used only to mint new access tokens when the old one expires. This keeps the user logged in without re-prompting, while the high-value secret is exchanged infrequently and over the back channel.

Refresh-token rotation

Best practice (RFC 9700) is one-time-use refresh tokens with rotation: each refresh returns a new refresh token and invalidates the old one. The key benefit is theft detection — if a previously-used (now invalidated) refresh token is presented again, that means two parties hold copies. The server treats it as compromise and revokes the entire token family, logging the user out everywhere.

Sessions: idle vs absolute timeouts

For server-side sessions, combine an idle timeout (expire after inactivity) with an absolute timeout (hard cap regardless of activity). Bind sessions to a secure, HttpOnly, SameSite cookie, and regenerate the session ID on privilege change (e.g. after login) to defeat fixation.

Storage pitfalls

In browsers, prefer HttpOnly cookies over localStorage, which is readable by any XSS payload. Always offer explicit logout and server-side revocation for the long-lived credential.

What interviewers look for: you contrast short access / longer refresh lifetimes, you can explain how rotation turns refresh reuse into a theft alarm, and you know stateless JWTs trade revocability for short expiry.