Por que você precisa tanto de um access token quanto de um refresh token?

Question

IT Interview Practice · Accepted Answer

Os dois tokens existem para resolver um conflito direto: um access token deve ser **enviado em toda requisição** (então fica muito exposto), mas você também quer sessões que **durem muito tempo** sem forçar logins frequentes. Você não pode ter ambos com segurança em um único token — então divide o trabalho.

## Os dois papéis

- **Access token** — de vida curta (tipicamente 5–15 minutos), enviado no cabeçalho `Authorization` em toda chamada de API. Como é transmitido constantemente, um vazamento é provável; mantê-lo curto significa que um roubado expira quase imediatamente.
- **Refresh token** — de vida longa (dias/semanas), enviado **apenas** ao endpoint de token do servidor de autenticação para obter novos access tokens. Ele trafega raramente, pode ser armazenado com mais segurança e pode ser revogado no lado do servidor.

```
Login ──▶ access (15m) + refresh (30d)
Toda chamada de API ──▶ envia access
Access expirado ──▶ envia refresh ──▶ novo access (+ refresh rotacionado)
```

## Por que não apenas um token?

| | Um access token de vida longa | Access + refresh |
|---|---|---|
| Exposição | Enviado a cada requisição, vive muito → grande janela de roubo | Access de vida curta; refresh raramente enviado |
| Revogação | Difícil (JWT stateless não pode ser des-emitido) | Revogue o refresh token; o access morre em minutos |
| UX | Re-login frequente se curto | Permanece logado sem reinserir credenciais |
| Raio de impacto do vazamento | Grande | Pequeno (access expira rápido) |

- **Um access token curto, sem refresh** → seguro, mas o usuário é desconectado a cada poucos minutos. UX terrível.
- **Um access token longo** → ótimo UX, mas um token vazado é válido por muito tempo e não pode ser facilmente revogado.
- **Access + refresh** → janela de exposição curta *e* sessões longas. O refresh token é o único segredo de vida longa, e ele vive em um único lugar seguro.

## O que a divisão possibilita

- **Revogação apesar de access tokens stateless.** Você não pode invalidar um access token JWT antes de ele expirar, mas *pode* deletar/negar o refresh token, então a sessão termina no próximo refresh (em minutos).
- **Rotação de refresh token** — emita um novo refresh token a cada uso e detecte a reutilização de um antigo (sinal de roubo), então revogue toda a cadeia.
- **Mínima exposição** — o segredo de vida longa (refresh) é enviado a exatamente um endpoint, idealmente armazenado em um cookie `httpOnly`, fora do alcance do XSS.

## Por que isso importa

Este é o design de autenticação moderno padrão, e os entrevistadores perguntam para ver se você entende o *porquê*, não apenas o *como*. O insight chave é o trade-off: statelessness e exposição curta (access) versus sessões longas e revogabilidade (refresh). Errar isso — um access token de vida longa, sem rotação, refresh armazenado em `localStorage` — transforma um único token vazado em um comprometimento de conta de longa duração. Nomear a divisão e o que cada token lhe proporciona é o que se espera que um engenheiro consciente de segurança saiba.

	Um access token de vida longa	Access + refresh
Exposição	Enviado a cada requisição, vive muito → grande janela de roubo	Access de vida curta; refresh raramente enviado
Revogação	Difícil (JWT stateless não pode ser des-emitido)	Revogue o refresh token; o access morre em minutos
UX	Re-login frequente se curto	Permanece logado sem reinserir credenciais
Raio de impacto do vazamento	Grande	Pequeno (access expira rápido)

Os dois papéis

Por que não apenas um token?

O que a divisão possibilita

Por que isso importa

Perguntas relacionadas