Access tokens vs refresh tokens

Published 18 October 2026

A hotel gives you a key card that opens your room until checkout. Lose it on day one and a thief has your room for a week. A better hotel gives you a card that works for one day, and a receipt you keep in the safe. Each morning you show the receipt at the front desk and get a new card. A thief who grabs today's card gets one day, and the receipt never leaves the room.

The key card is an access token. The receipt is a refresh token. That is the entire idea: one token that is used constantly and lives briefly, and one that is used rarely, lives long and can be cancelled.

Two tokens, two jobs#

The refresh token's safety comes from where it goes, not from being stronger. An access token is attached to hundreds of requests, passes through API gateways, logs, proxies and every microservice. A refresh token is sent to exactly one endpoint, rarely. Less exposure, and when something does go wrong, one database row to delete.

The refresh dance#

Good clients refresh a little before expiry rather than waiting for the 401, which saves a failed round trip. They still handle the 401, because clocks drift and tokens get revoked.

Rotation and reuse detection#

Rotation means every refresh returns a new refresh token and kills the old one. That alone does not stop a thief who uses the stolen token first. What makes it powerful is reuse detection: the server remembers the whole chain of tokens it issued to one login, and if any old, already spent token shows up again, someone has a copy. The server does not know which side is the thief, so it revokes the entire chain and both have to log in again. The attacker is out; the real user is mildly annoyed.

This is the recommendation in the IETF's OAuth security best practice (RFC 9700, published January 2025) for public clients like SPAs and mobile apps, where the refresh token cannot be bound to a client secret.

// Every caller that hits a 401 at the same time waits on the same promise,
// so only one refresh request ever goes out from this tab.
let inflight: Promise<string> | null = null
 
export function refreshAccessToken(): Promise<string> {
  if (!inflight) {
    inflight = fetch('/auth/refresh', { method: 'POST', credentials: 'include' })
      .then((r) => {
        if (!r.ok) throw new Error('session ended')
        return r.json()
      })
      .then((body) => body.accessToken)
      .finally(() => {
        inflight = null
      })
  }
  return inflight
}

Picking lifetimes#

The access token lifetime is your worst case for revocation and your refresh load at the same time. Shorter is safer and costs more trips to the auth server. Put numbers on it.

For refresh tokens, two clocks matter. An idle timeout (say 14 days without use) logs out abandoned devices. An absolute lifetime (say 90 days) forces a real login now and then, even for active users, which is when MFA gets asked again. Banking apps use much shorter values than social apps, and they should.

Where to keep them#

In the interview#

Checkpoint#