intermediateRefresh Tokens & Session Lifecycle

Why use a short-lived access token plus a separate long-lived refresh token instead of one long-lived token?

A short access token (minutes) limits the damage window if it's ever stolen — it expires quickly regardless. The refresh token lives longer but is only ever sent to a single dedicated token-refresh endpoint (never to regular API endpoints), so it's exposed to far fewer network paths, and it can be revoked server-side (stored, rotated, or blacklisted) unlike a stateless access token.

This is a Pro chapter

Sign in, then upgrade to Pro or Power to unlock this and the full Spring Ecosystem Mastery library.

Why use a short-lived access token plus a separate long-lived refresh token instead of one long-lived token?

Next Step

Continue to What is refresh token rotation, and what attack does it defend against?← Back to all Spring Boot questions