Do you actually need a refresh token?

If your access token is short-lived and your user is active, probably. If not, you're adding complexity for no benefit.

· LoginWith team

Refresh tokens are one of those OAuth features that every tutorial mentions and every team implements without asking whether they actually need them. Let’s ask the question.

What refresh tokens are for

A refresh token exists for one narrow purpose: keep a user signed in after their access token expires, without requiring them to go through the IdP redirect again. The client sends the refresh token to the token endpoint, receives a new access token (and ideally a new refresh token), and carries on.

This is useful when:

  1. Your access tokens are short-lived (minutes to an hour), and
  2. Your users are active across long sessions, and
  3. Redirecting them to the IdP every hour would be terrible UX.

Remove any one of those conditions and the refresh token is doing no meaningful work.

When you don’t need one

If your access tokens live 24 hours, refresh tokens are mostly an afterthought. The user will either be logged in for the whole day or come back later and re-auth — no in-session refresh needed.

If you’re using first-party cookies for session management (server-side sessions keyed by a cookie), your access tokens only need to live as long as a single API call. A JWT that expires in 5 minutes and is generated fresh by your backend on each request has no need for client-side refresh.

If your integration is server-to-server, you want the client_credentials grant, not user-scoped refresh tokens.

When you absolutely do

SPAs and native apps that hit third-party APIs directly (without a backend broker) need refresh tokens — otherwise the user is one hour away from being kicked out. In this case you must also implement refresh token rotation: every use returns a new refresh token, and reuse of an old one is a leak signal.

Offline access to third-party APIs (nightly background jobs calling Google Calendar, say) requires refresh tokens — you’re calling the API when the user isn’t present.

The rule

Use refresh tokens when you have to. When you have the option of server-side sessions instead, take it. One less moving part, one less place for rotation bugs, one less class of token to store safely.

Want auth that just works?

Get started with LoginWith