¿Por qué necesitas tanto un access token como un refresh token?

Question

IT Interview Practice · Accepted Answer

Los dos tokens existen para resolver un conflicto directo: un access token debe **enviarse en cada request** (por lo que queda muy expuesto), pero a la vez quieres sesiones que **duren mucho tiempo** sin forzar logins frecuentes. No puedes tener ambas cosas de forma segura en un solo token — así que divides la tarea.

## Los dos roles

- **Access token** — de vida corta (normalmente 5–15 minutos), enviado en el header `Authorization` en cada llamada a la API. Como se transmite constantemente, una fuga es probable; mantenerlo corto significa que uno robado expira casi de inmediato.
- **Refresh token** — de vida larga (días/semanas), enviado **solo** al token endpoint del servidor de auth para obtener nuevos access tokens. Viaja rara vez, puede almacenarse de forma más segura y puede revocarse en el servidor.

```
Login ──▶ access (15m) + refresh (30d)
Every API call ──▶ send access
Access expired ──▶ send refresh ──▶ new access (+ rotated refresh)
```

## ¿Por qué no un solo token?

| | Un access token de vida larga | Access + refresh |
|---|---|---|
| Exposición | Enviado en cada request, vive mucho → gran ventana de robo | Access de vida corta; refresh enviado rara vez |
| Revocación | Difícil (un JWT stateless no se puede desemitir) | Revoca el refresh token; el access muere en minutos |
| UX | Re-login frecuente si es corto | Sigue con sesión iniciada sin reintroducir credenciales |
| Radio de impacto de una fuga | Grande | Pequeño (el access expira rápido) |

- **Un access token corto, sin refresh** → seguro, pero al usuario se le cierra la sesión cada pocos minutos. UX terrible.
- **Un access token largo** → gran UX, pero un token filtrado es válido durante mucho tiempo y no se puede revocar con facilidad.
- **Access + refresh** → ventana de exposición corta *y* sesiones largas. El refresh token es el único secreto de vida larga, y vive en un único lugar seguro.

## Qué permite la división

- **Revocación pese a los access tokens stateless.** No puedes invalidar un JWT access token antes de que expire, pero *sí* puedes eliminar/denegar el refresh token, así que la sesión termina en el siguiente refresh (en minutos).
- **Rotación del refresh token** — emite un nuevo refresh token en cada uso y detecta la reutilización de uno antiguo (señal de robo), luego revoca toda la cadena.
- **Mínima exposición** — el secreto de vida larga (refresh) se envía a exactamente un endpoint, idealmente almacenado en una cookie `httpOnly`, fuera del alcance de XSS.

## Por qué es importante

Este es el diseño de auth moderno estándar, y los entrevistadores lo preguntan para ver si entiendes el *porqué*, no solo el *cómo*. La idea clave es la concesión: statelessness y exposición corta (access) frente a sesiones largas y revocabilidad (refresh). Hacerlo mal — un access token de vida larga, sin rotación, refresh almacenado en `localStorage` — convierte un único token filtrado en un compromiso de cuenta de larga duración. Nombrar la división y lo que cada token te aporta es lo que se espera que sepa un ingeniero consciente de la seguridad.

	Un access token de vida larga	Access + refresh
Exposición	Enviado en cada request, vive mucho → gran ventana de robo	Access de vida corta; refresh enviado rara vez
Revocación	Difícil (un JWT stateless no se puede desemitir)	Revoca el refresh token; el access muere en minutos
UX	Re-login frecuente si es corto	Sigue con sesión iniciada sin reintroducir credenciales
Radio de impacto de una fuga	Grande	Pequeño (el access expira rápido)

Los dos roles

¿Por qué no un solo token?

Qué permite la división

Por qué es importante

Preguntas relacionadas