HTTP no tiene estado — entonces, ¿cómo funcionan las sesiones?
Respuesta breve
HTTP no tiene estado — cada petición es independiente y no guarda memoria de las anteriores. Las sesiones añaden estado por encima: tras iniciar sesión, el servidor emite un identificador que el navegador almacena en una cookie y reenvía en cada petición. Las sesiones del lado del servidor mantienen el estado en el servidor indexado por un ID de sesión opaco; los tokens sin estado como los JWT ponen el estado firmado en el propio token para que el servidor pueda verificar sin almacenamiento.
HTTP no tiene estado por diseño: cada petición es independiente, y el servidor no conserva ninguna memoria integrada de quién envió la anterior. Esa simplicidad escala maravillosamente, pero entra en conflicto con la necesidad de mantener la «sesión iniciada». Las sesiones son la capa que añade continuidad de identidad sobre un protocolo sin estado.
El mecanismo central
Después de autenticarte una vez, el servidor emite un identificador y el navegador lo almacena — casi siempre en una cookie. Como los navegadores adjuntan automáticamente las cookies a cada petición posterior a ese sitio, el servidor puede reconocerte en cada petición sin que te vuelvas a autenticar. La cookie es una credencial al portador, por lo que sus atributos (HttpOnly, Secure, SameSite) importan tanto.
Dos formas de mantener el estado
Sesiones del lado del servidor (con estado). La cookie contiene un ID de sesión opaco y aleatorio. El servidor guarda los datos reales de la sesión (ID de usuario, roles, caducidad) en su propio almacén — memoria, Redis, una base de datos — indexado por ese ID. Ventajas: el servidor puede revocar una sesión al instante eliminándola, y ningún dato sensible reside en la cookie. Coste: el servidor (o un almacén compartido) debe mantener el estado, lo que añade infraestructura al escalar horizontalmente.
Tokens sin estado (por ejemplo, JWT). El propio token lleva las reclamaciones (usuario, roles, caducidad) y está firmado criptográficamente. El servidor verifica la firma en cada petición y confía en el contenido — sin necesidad de búsqueda. Ventajas: escala fácilmente entre muchos servidores sin un almacén de sesiones compartido. Costes: el token es válido hasta que expira, por lo que la revocación es difícil (necesitas una lista de denegación o vidas cortas más tokens de actualización), y reclamaciones excesivas o sensibles pueden filtrarse.
Por qué el ID debe ser impredecible
Ya sea un ID opaco o un token firmado, si un atacante puede adivinarlo, forzarlo por fuerza bruta o falsificarlo, secuestra la sesión. Por eso los ID de sesión deben ser largos y proceder de un CSPRNG, y los tokens deben usar una firma fuerte con el algoritmo fijado en el servidor.
Los entrevistadores buscan «HTTP no tiene estado, las cookies llevan un identificador», el compromiso con estado vs sin estado (revocación vs escalabilidad), y el requisito de seguridad de que el identificador sea inadivinable.
Posibles preguntas de seguimiento
- ¿Cuáles son los compromisos entre las sesiones del lado del servidor y los JWT sin estado?
- ¿Cómo se revoca un JWT sin estado antes de que expire?
- ¿Por qué un ID de sesión debe ser largo e impredecible?