Sesiones, cookies y tokens

HTTP es un protocolo sin estado: cada petición llega sola, sin recuerdo de las anteriores. Si un usuario inicia sesión y en la siguiente petición el servidor ya no sabe quién es, algo tiene que viajar con cada petición para recordárselo. Hay dos grandes formas de hacerlo.

Analogía

Guardarropa o pulsera de festival

Con el guardarropa, el ticket no vale nada por sí mismo: es solo un número que el local busca en su registro. Con la pulsera, la propia pulsera es la información, y cualquier portero puede comprobarla sin preguntar a nadie. Más cómodo para escalar, pero difícil de anular antes de tiempo.

En el mundo realEn tu sistema

Ticket del guardarropa con un númeroID de sesión en una cookie

El abrigo se queda en el localLos datos del usuario se quedan en el servidor

Romper el ticket invalida la recogida al instanteCerrar sesión es inmediato

Pulsera con holograma que dice "zona VIP"Token (JWT) firmado que lleva los permisos

El portero solo mira el holograma, no llama a nadieLa API valida la firma sin consultar la base de datos

Una pulsera robada vale hasta que caduqueUn token robado es válido hasta su exp

Sesión con cookie (stateful)

La cookie solo transporta un identificador opaco; la identidad vive en el servidor.

La cookie es automática: el navegador la adjunta a cada petición hacia ese dominio sin que el JavaScript haga nada. Esa comodidad es también su mayor riesgo (lo verás en la lección de CSRF).

Anatomía de una cookie segura

HTTP/1.1 200 OK
Set-Cookie: __Host-SESSION=8f2c41d0e9; Path=/; Secure; HttpOnly; SameSite=Lax; Max-Age=1800

Atributo	Qué hace	Qué evita
HttpOnly	JavaScript no puede leerla (document.cookie no la ve)	Que un XSS robe la sesión
Secure	Solo viaja por HTTPS	Que se lea en una red Wi-Fi o un proxy
SameSite=Lax	No se envía en peticiones POST iniciadas por otros sitios (sí al seguir un enlace)	La mayoría de ataques CSRF
SameSite=Strict	No se envía en ninguna petición iniciada por otro sitio	CSRF por completo, a costa de que un enlace externo llegue “sin sesión”
SameSite=None	Se envía siempre (exige Secure)	Nada: solo para integraciones cross-site legítimas
Max-Age / Expires	Duración. Sin ellos, cookie de sesión del navegador	Sesiones eternas
Prefijo __Host-	Obliga a Secure, Path=/ y sin Domain	Que un subdominio comprometido la sobrescriba

Idea clave

Una cookie de sesión debe ser, como mínimo, HttpOnly, Secure y SameSite=Lax. Y su valor debe ser un identificador aleatorio largo, sin ningún significado: no un id de usuario, no un email.

Token Bearer (stateless)

En el modelo con token, el cliente recibe una credencial y la envía explícitamente en una cabecera:

GET /api/notes HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJhbmEi...

“Bearer” significa “portador”: quien lo porta, lo usa. No hay más comprobación de identidad que poseerlo, así que un token robado equivale a una sesión robada.

Los tokens pueden ser:

• Opacos: una cadena aleatoria sin significado. La API debe preguntar al emisor qué significa (introspección). Revocables al instante, pero con una llamada extra por petición.
• Autocontenidos (JWT): llevan los datos dentro, firmados. La API los valida sola, con la clave pública del emisor.

Anatomía de un JWT

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6ImsxIn0.eyJpc3MiOiJodHRwczovL2F1dGguZXhhbXBsZS5jb20iLCJzdWIiOiJhbmEiLCJzY29wZSI6Im5vdGVzOnJlYWQiLCJleHAiOjE3OTM3MDAwMDB9.Qm9vb2hfc2lnbmF0dXJlX2J5dGVzX2Jhc2U2NHVybA

Header

{
  "alg": "RS256",
  "typ": "JWT",
  "kid": "k1"
}

cómo se firmó

Payload (claims)

{
  "iss": "https://auth.example.com",
  "sub": "ana",
  "scope": "notes:read",
  "exp": 1793700000
}

lo puede leer CUALQUIERA — nunca pongas secretos

Firma

RS256(
  base64url(header) + "." +
  base64url(payload),
  privateKey
)

prueba que nadie cambió header ni payload

Tres partes en Base64URL separadas por puntos. El payload se lee; la firma impide modificarlo.

Claim	Significado
iss	Quién lo emitió (issuer)
sub	De quién es (subject): el usuario o el cliente
aud	Para quién es (audience): qué API debe aceptarlo
exp / nbf / iat	Caduca en / no válido antes de / emitido en (segundos Unix)
scope	Permisos concedidos
jti	Identificador único (para detectar reutilizaciones o revocar)

Trampa común

Creer que un JWT está cifrado

El payload de un JWT firmado (JWS) solo está codificado en Base64URL. Cualquiera que lo intercepte lee su contenido. Nunca pongas en un JWT contraseñas, datos personales sensibles ni nada que no publicarías: solo identificadores, permisos y fechas. (Existe el JWT cifrado, JWE, pero es otra cosa y mucho menos común).

Trampa común

Validar un JWT a mano

Decodificar el payload no es validarlo. Validar significa: comprobar la firma con la clave correcta y un algoritmo fijado por el servidor (nunca el que dice el header: el famoso alg: none), y después exp, nbf, iss y aud. Usa una librería o el soporte de tu framework; en Spring es el resource server.

¿Sesión o token?

	Sesión (cookie)	Token (Bearer)
Dónde vive la identidad	En el servidor	En el token
Cerrar sesión / revocar	Inmediato: borrar la sesión	Difícil: vale hasta que expira
Escalar a varias instancias	Necesita sesión compartida (Redis)	Trivial: cualquier instancia valida la firma
Riesgo típico	CSRF (la cookie va sola)	Robo del token (XSS si está en localStorage)
Clientes ideales	Web del mismo dominio, BFF	Móviles, servicios, APIs públicas

Ninguna opción es “la moderna”. Si el único cliente es una web de tu propio dominio, una sesión con cookie HttpOnly y protección CSRF suele ser más segura que un JWT accesible desde JavaScript.

Tokens de acceso y de refresco

Como un token no se puede revocar fácilmente, se hace de vida corta (5–15 minutos). Para no pedir la contraseña cada cuarto de hora, el cliente recibe además un refresh token de vida larga que solo sirve para pedir un access token nuevo al emisor, que sí lo guarda y lo puede revocar. Si además cada uso del refresh token lo reemplaza por otro (rotación), un refresh token robado y reutilizado se detecta.

¿Dónde guarda el token una SPA?

Lugar	Riesgo
localStorage / sessionStorage	Cualquier XSS lo lee y lo envía a otro servidor
Memoria de la app (variable JS)	Un XSS aún puede usarlo mientras la página está abierta, pero no robarlo para después; se pierde al recargar
Cookie HttpOnly gestionada por un backend propio (BFF)	El JavaScript nunca ve el token. Hay que proteger CSRF

La recomendación actual para SPAs es el patrón BFF (Backend for Frontend): un backend de tu dominio hace el login OAuth2, guarda los tokens del lado del servidor y al navegador solo le da una cookie de sesión HttpOnly.

Mini lab · 10 min

Lee un JWT como lo haría un atacante

Marcar como completado

Objetivo: Decodificar un token, interpretar sus claims y razonar qué protege la firma.

Este es un token de ejemplo (la firma es falsa):

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6ImsxIn0.eyJpc3MiOiJodHRwczovL2F1dGguZXhhbXBsZS5jb20iLCJzdWIiOiJhbmEiLCJzY29wZSI6Im5vdGVzOnJlYWQgbm90ZXM6d3JpdGUiLCJpYXQiOjE3OTM3MDAwMDAsImV4cCI6MTc5MzcwMDkwMH0.c2lnbmF0dXJlLWRlLWVqZW1wbG8

Decodifica el payload en la consola del navegador:

const token = 'eyJhbGciOi...';   // pega el token completo
JSON.parse(atob(token.split('.')[1].replace(/-/g, '+').replace(/_/g, '/')));

1. ¿De quién es el token, quién lo emitió y qué permisos tiene?
2. ¿Cuánto tiempo es válido desde que se emitió?
3. Si cambias "notes:read notes:write" por "notes:read notes:write notes:admin", vuelves a codificar el payload y envías el token, ¿qué debería responder una API bien configurada?
4. ¿Falta algún claim que una API debería exigir?

Pista

exp e iat son segundos desde 1970. Réstalos.

Mostrar respuestaOcultar respuesta

1. sub: "ana", emitido por iss: "https://auth.example.com", con scope: "notes:read notes:write". Todo esto lo puede leer cualquiera que vea el token.
2. exp − iat = 900 segundos: 15 minutos, una duración típica de access token.
3. 401. La firma se calculó sobre el header y el payload originales; al cambiar un solo carácter, la verificación con la clave pública falla. Por eso puedes leer un JWT pero no modificarlo. (Si la API aceptara el token, estaría validando mal: por ejemplo, sin comprobar la firma o aceptando alg: none).
4. Falta aud. Sin audiencia, un token emitido para otra API del mismo emisor serviría también aquí. Una API debería exigir que aud la incluya.

En resumen

• HTTP no tiene estado: o una cookie lleva un id de sesión, o cada petición lleva un token.
• Cookies de sesión: HttpOnly, Secure, SameSite=Lax (o Strict) y un valor aleatorio.
• Un JWT firmado se lee pero no se modifica; validarlo es firma + algoritmo fijo + exp/iss/aud.
• Access tokens cortos + refresh tokens rotados; en SPAs, preferible el patrón BFF a localStorage.