Como os access tokens e os refresh tokens funcionam juntos?

Question

IT Interview Practice · Accepted Answer

Os dois tokens seguem um ciclo de vida simples: um **access token de vida curta** autoriza cada chamada de API, e um **refresh token de vida longa** silenciosamente cunha novos access tokens quando eles expiram — assim o usuário permanece logado sem reinserir credenciais.

## O fluxo

```
┌─────────┐  1. login (user + pass)   ┌────────────┐
│ Client  │ ────────────────────────▶ │ Auth server│
│         │ ◀──── access + refresh ─── │            │
└─────────┘                            └────────────┘
     │  2. chamada de API: Authorization: Bearer <access>
     ▼
┌────────────┐  verifica assinatura + exp   (sem consulta ao DB)
│ Resource   │ ──── 200 OK ────▶ (access ainda válido)
│ API        │ ──── 401 ───────▶ (access expirado)
└────────────┘
     │  3. no 401: POST /token { refresh }
     ▼
┌────────────┐  verifica + rotaciona
│ Auth server│ ──── novo access (+ novo refresh) ────▶ repete a chamada
└────────────┘
```

1. **Login** — o usuário se autentica uma vez; o servidor retorna um **access token** (TTL curto) e um **refresh token** (TTL longo).
2. **Acessar APIs** — o cliente envia o access token em `Authorization: Bearer …` em toda requisição. A API o verifica de forma stateless (assinatura + `exp`) e responde — nenhum armazenamento de sessão necessário.
3. **Refresh na expiração** — quando a API retorna `401` (ou o cliente vê que `exp` está próximo), o cliente faz POST do **refresh token** ao endpoint `/token` do servidor de autenticação e obtém um access token novo, depois repete a requisição original. O usuário não percebe nada.
4. **Logout / revogar** — o servidor deleta ou coloca o refresh token em denylist; o próximo refresh falha e a sessão termina (o access token atual ainda morre sozinho em minutos).

```js
// Interceptor do cliente: refresh uma vez no 401, depois repete.
async function apiFetch(url, opts = {}) {
  let res = await fetch(url, withAuth(opts, accessToken));
  if (res.status === 401) {
    accessToken = await refreshAccessToken(refreshToken); // POST /token
    res = await fetch(url, withAuth(opts, accessToken));   // repete
  }
  return res;
}
```

## Rotação de refresh token

A melhor prática é a **rotação**: cada chamada de refresh retorna um *novo* refresh token e invalida o antigo. Se um refresh token antigo (já usado) for apresentado novamente, isso sinaliza roubo — o servidor revoga toda a família de tokens e força novo login. Isso limita o dano de um refresh token roubado.

## Armazenamento

- **Refresh token** → cookie `httpOnly`, `Secure`, `SameSite` para que o JavaScript (e portanto o XSS) não possa lê-lo.
- **Access token** → mantido em memória no cliente; a vida curta limita a exposição.
- Nunca coloque nenhum dos dois em `localStorage` se puder evitar — é legível por qualquer script injetado.

## Por que isso importa

Este fluxo é a espinha dorsal do gerenciamento de sessão em SPAs, apps móveis e APIs modernos, então os entrevistadores esperam que você o rastreie de ponta a ponta: emita ambos no login, autorize com o access token, faça refresh de forma transparente na expiração e rotacione + revogue por segurança. Acertar os detalhes — verificação stateless, refresh somente no endpoint de token, rotação com detecção de reutilização e armazenamento `httpOnly` — é a diferença entre uma sessão suave e segura e uma em que um único token roubado significa uma tomada de conta de longa duração.

O fluxo

Rotação de refresh token

Armazenamento

Por que isso importa

Perguntas relacionadas