Refresh Token
A long-lived credential used solely to obtain new short-lived access tokens, so sessions can persist without long-lived access tokens circulating.
The mechanism that resolves the JWT revocation problem in practice. Access tokens are short — minutes — so a stolen one expires quickly; the refresh token carries the session and is presented only to the authorisation server, which can check it against current state and refuse.
The properties that matter:
Rotation. Each use issues a new refresh token and invalidates the old one. This is what makes theft detectable rather than merely possible.
Reuse detection. If an already-used refresh token is presented, either the legitimate client or an attacker is replaying it — and since you cannot tell which, the correct response is to revoke the entire token family and force re-authentication. This is the single most valuable control on refresh tokens and it is frequently omitted.
Storage. In a browser, an HttpOnly, Secure, SameSite cookie rather than local storage, which
is readable by any script and therefore by any XSS. On mobile, the platform keystore.
Binding. Where supported, bind the token to a client instance or a device so it is not usable elsewhere.
The design question underneath: refresh token lifetime is your session length, and it should be set from the sensitivity of what the session grants rather than from convenience.