refresh token

Modern web and mobile applications often depend on token-based authentication. Instead of storing user state directly on the server, systems sign credentials and send them with requests. This model works well for distributed APIs, microservices, and single-page applications. It also allows different services to verify identity without repeated database lookups.

The Two-Token Pattern

A refresh token is a long-lived credential used to obtain a new access token after the current one expires.

In OAuth 2.0, JWT-based authentication, and similar frameworks, tokens usually fall into two groups:

• Access token: A short-lived token used to access protected resources. Its lifetime may be only 15 minutes. If exposed, the attacker has a limited window to use it.
• Refresh token: A longer-lived token used to request a new access token. Its lifetime may be days or weeks. It is typically sent only to the token endpoint.

The pattern combines a short access token with a longer refresh token. That gives the system quick validation on individual requests and a controlled path for renewal.

Why Short Access Tokens Matter

If only a long-lived access token exists, the design becomes risky. A leaked token could remain useful for a long period. A stateless JWT can be difficult to revoke immediately without extra state.

With a refresh token, access tokens can be kept short. Even if an access token leaks, the potential abuse window is small. The refresh token is used less often and can be rotated or revoked by the server.

How Refresh Tokens Work

A typical flow may look like this:

1. The user authenticates through a password, passkey, or another method.
2. The authorization server issues an access token and a refresh token.
3. The client sends the access token with API requests.
4. The access token expires, and the API returns an error.
5. The client uses the refresh token to request a new access token.
6. The server validates the refresh token and issues a new access token.
7. The server may rotate the refresh token and invalidate the old one.
8. If the refresh token is invalid or expired, the user may need to authenticate again.

Rotation is an important security practice. Each refresh can produce a new refresh token, and the previous token can be marked as used.

Access Token Versus Refresh Token

Security Practices

• Shorten access token lifetime: Keep it in minutes when practical.
• Rotate refresh tokens: Issue a new token and invalidate the old one.
• Store tokens securely: Use HttpOnly, Secure, and SameSite cookies in browsers. Use Keychain or Keystore on mobile.
• Bind tokens to context: Consider device, IP, or user agent signals.
• Support revocation: Revoke on logout, password change, or account action.
• Limit scope: Refresh tokens should not act as general-purpose credentials.

The exact values depend on the risk profile of the application, but shorter access token lifetimes generally reduce exposure. Refresh token rotation helps detect replay attacks. Secure storage remains essential because a stolen refresh token can be more valuable than a short access token.

Design Considerations

Refresh token delivery matters. Browser clients often use cookies, while mobile and server-side clients may store tokens in secure storage. The authorization server and client must agree on storage, rotation, and revocation behavior.

Refresh token reuse detection can also help. If a refresh token is reused after rotation, the system may treat it as suspicious and revoke related tokens.

Final Thoughts

Refresh tokens create a balance between security and usability. Short access tokens reduce exposure, while refresh tokens support controlled renewal. A well-designed implementation uses short access tokens, secure storage, rotation, and revocation. When these practices are applied consistently, token-based authentication becomes more resilient and easier to manage.