How refresh tokens work
OAuth 2.0 splits a session into two tokens with opposite properties. The access token is short-lived, often minutes, and is presented to APIs on every request. The refresh token is long-lived, is never sent to APIs, and has exactly one job: when the access token expires, the client presents the refresh token to the authorization server's token endpoint and receives a fresh access token, usually together with a new refresh token.
This division limits damage. If an access token leaks, it dies on its own within minutes. The refresh token, which would be the valuable prize, travels only between the client and the authorization server over a single hardened endpoint, where every use can be validated against revocation lists, client identity, and anomaly checks before new tokens are issued.
Why refresh tokens matter
Without refresh tokens, systems face an ugly choice: issue long-lived access tokens that are dangerous when stolen and nearly impossible to revoke, or force users to re-authenticate every few minutes. Refresh tokens dissolve the dilemma, delivering the user experience of a long session with the security profile of short-lived credentials.
They are also the control point for revocation. Because every renewal passes through the authorization server, administrators can cut off a user, device, or application by invalidating the refresh token; the current access token then simply runs out. Refresh token rotation strengthens this further: each use issues a replacement and invalidates the old token, so a stolen token that gets replayed collides with its successor and the server can revoke the entire family.
Refresh tokens in practice
Handling depends on the client type. Server-side applications keep refresh tokens in protected server storage. Native and mobile apps use platform keychains. Browser-based single-page applications are the hardest case, since anything readable by JavaScript is exposed to cross-site scripting; current guidance favors rotation with short refresh token lifetimes, or keeping tokens out of the browser entirely behind a backend-for-frontend.
Operationally, teams should enable rotation and reuse detection, scope refresh token lifetimes to the sensitivity of the application, and tie token revocation into offboarding so disabling a user genuinely ends their access. As an OIDC provider, Monosign issues and manages tokens under centrally defined session and lifetime policies.