Secure refresh token flow for access renewal

WHAT THIS TESTS Whether you understand why two token types exist and can describe a renewal flow that limits the blast radius of a leaked token while keeping users logged in.

A GOOD ANSWER COVERS Use two tokens. The access token is short-lived, perhaps a handful of minutes, and is sent with every request; its short life limits damage if stolen. The refresh token is longer-lived, perhaps days or weeks, and is used only to obtain new access tokens. Store a representation of the refresh token server-side, ideally hashed, so it can be revoked, and deliver it to the browser in an HttpOnly, Secure, SameSite cookie rather than localStorage to resist XSS theft. When the access token expires, the client calls a refresh endpoint that authenticates the refresh token, checks it has not been revoked, then performs rotation: it issues a new access token and a new refresh token and invalidates the old refresh token. Rotation plus reuse detection means if an old refresh token is replayed, you can revoke the whole token family, assuming theft. Logout deletes the stored refresh token.

COMMON WRONG ANSWERS Making the access token long-lived so renewal is rarely needed, defeating the security benefit. Storing refresh tokens in localStorage where XSS can steal them. Never rotating or persisting refresh tokens, so they cannot be revoked. Returning the same refresh token forever.

LIKELY FOLLOW-UPS What is refresh-token rotation and reuse detection? Why HttpOnly cookies over localStorage? How do you revoke all sessions for a user?

ONE CONCRETE EXAMPLE Login returns a 5-minute access token in the body and a 14-day refresh token in an HttpOnly cookie, with its hash stored in the database. After 5 minutes the client POSTs /auth/refresh; the server validates and rotates the refresh token, marks the old one used, and returns a new access token. If the old refresh token is later replayed, reuse detection revokes the family and forces re-login.