Why use long-lived refresh tokens if access tokens expire quickly?

Think of the access token as a temporary ticket and the refresh token as a protected pass that lets you get a new ticket. Access tokens are sent with normal API requests, so they have more opportunities to leak. Refresh tokens should be exposed much less often—typically only to the authentication server’s refresh endpoint. HttpOnly prevents page JavaScript from reading the cookie, although it doesn’t make the token completely risk-free.

You don’t always need this design. For a simple monolithic application, a traditional server-side session ID in an HttpOnly cookie is often easier and safer. Access and refresh tokens become more useful when multiple independent services need to validate authentication without querying a central session store on every request. JWTs can help with that because services can verify the signature locally, but they also make immediate revocation more complicated.

The authentication server can track refresh tokens and revoke them, while resource services can often validate signed access tokens locally without contacting the authentication server on every request. That makes access-token validation fast and scalable. If an access token is compromised, its short lifetime limits the window of misuse; if a refresh token is compromised, the server can stop issuing new access tokens by revoking it. For higher-risk operations, a service can also perform additional revocation or session checks.

This is mainly about limiting damage, not making theft impossible. If someone steals an access token, they can usually use it only until its short expiration time. A refresh token is more valuable, so it needs stronger protection: HTTPS, Secure and HttpOnly cookie settings, a narrow path or domain scope, CSRF defenses, and preferably refresh-token rotation. After a successful refresh, the old refresh token is invalidated. If that old token is used again, the server can detect possible theft and revoke the whole token family.