¿Cómo funcionan juntos los access tokens y los refresh tokens?

Question

IT Interview Practice · Accepted Answer

Los dos tokens siguen un ciclo de vida simple: un **access token de vida corta** autoriza cada llamada a la API, y un **refresh token de vida larga** acuña silenciosamente nuevos access tokens cuando expiran — de modo que el usuario sigue con la sesión iniciada sin reintroducir credenciales.

## El flujo

```
┌─────────┐  1. login (user + pass)   ┌────────────┐
│ Client  │ ────────────────────────▶ │ Auth server│
│         │ ◀──── access + refresh ─── │            │
└─────────┘                            └────────────┘
     │  2. API call: Authorization: Bearer <access>
     ▼
┌────────────┐  verify signature + exp   (no DB lookup)
│ Resource   │ ──── 200 OK ────▶ (access still valid)
│ API        │ ──── 401 ───────▶ (access expired)
└────────────┘
     │  3. on 401: POST /token { refresh }
     ▼
┌────────────┐  verify + rotate
│ Auth server│ ──── new access (+ new refresh) ────▶ retry the call
└────────────┘
```

1. **Login** — el usuario se autentica una vez; el servidor devuelve un **access token** (TTL corto) y un **refresh token** (TTL largo).
2. **Acceso a las APIs** — el cliente envía el access token en `Authorization: Bearer …` en cada request. El API lo verifica de forma stateless (firma + `exp`) y responde — sin necesidad de un almacén de sesiones.
3. **Refresh al expirar** — cuando el API devuelve `401` (o el cliente ve que `exp` está cerca), el cliente hace POST del **refresh token** al endpoint `/token` del servidor de auth y obtiene un access token nuevo, luego reintenta el request original. El usuario no nota nada.
4. **Logout / revocación** — el servidor elimina o pone en denylist el refresh token; el siguiente refresh falla y la sesión termina (el access token actual igualmente muere por sí solo en minutos).

```js
// Interceptor del cliente: refresca una vez en 401, luego reintenta.
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));   // reintentar
  }
  return res;
}
```

## Rotación del refresh token

La mejor práctica es la **rotación**: cada llamada de refresh devuelve un refresh token *nuevo* e invalida el antiguo. Si se presenta de nuevo un refresh token antiguo (ya usado), eso indica robo — el servidor revoca toda la familia de tokens y fuerza un nuevo login. Esto limita el daño de un refresh token robado.

## Almacenamiento

- **Refresh token** → cookie `httpOnly`, `Secure`, `SameSite` para que JavaScript (y por tanto XSS) no pueda leerlo.
- **Access token** → mantenido en memoria en el cliente; su vida corta limita la exposición.
- Nunca pongas ninguno en `localStorage` si puedes evitarlo — es legible por cualquier script inyectado.

## Por qué es importante

Este flujo es la columna vertebral de la gestión de sesiones en las SPAs, apps móviles y APIs modernas, así que los entrevistadores esperan que lo traces de principio a fin: emitir ambos en el login, autorizar con el access token, refrescar de forma transparente al expirar, y rotar + revocar por seguridad. Acertar en los detalles — verificación stateless, refresh solo en el token endpoint, rotación con detección de reutilización y almacenamiento `httpOnly` — es la diferencia entre una sesión fluida y segura y una en la que un único token robado significa una toma de cuenta de larga duración.

El flujo

Rotación del refresh token

Almacenamiento

Por qué es importante

Preguntas relacionadas