La comparación entre sesiones y tokens JWT define cómo construyes la autenticación en aplicaciones modernas. Aquí entiendes cuándo cada enfoque tiene sentido, qué problemas resuelve cada uno y por qué los JSON Web Tokens ganaron terreno frente a las sesiones tradicionales.

¿Cómo funciona el flujo de autenticación con sesiones?

Las sesiones llevan años sosteniendo la autenticación web, y su lógica es directa. Todo arranca cuando el usuario envía su nombre y contraseña desde un formulario hacia el servidor [01:00].

Ese envío viaja como un authorization request de tipo basic, donde el usuario y la contraseña se concatenan con dos puntos y se codifican. Tiene que viajar de forma segura, porque si no, las credenciales quedan expuestas.

El servidor valida que el usuario exista en la base de datos y que la contraseña coincida. Cuando todo cuadra, crea una sesión: un espacio en memoria que guarda información relevante de ese usuario, único por persona, con un ID propio.

¿Dónde se guarda el ID de sesión?

Ese ID normalmente se guarda en una cookie, y las cookies viajan asociadas a cada request entre cliente y servidor. Desde ese momento, cada solicitud lleva esa cookie con el ID, y así la aplicación reconoce a un usuario frente a otro.

¿Qué es una sesión en autenticación? Es un espacio en la memoria del servidor que almacena información del usuario autenticado y se identifica con un ID único, normalmente enviado al cliente dentro de una cookie.

¿Por qué las sesiones empezaron a quedarse cortas?

Las arquitecturas modernas pusieron a las sesiones contra la pared. Hay varios puntos de fricción concretos que conviene tener claros [02:30].

• Las Single Page Apps no se actualizan del lado del servidor, así que si el estado de la sesión cambia, no hay forma natural de comunicárselo al cliente.
• Las REST API deben ser stateless por definición, y mantener sesión contradice ese principio que llevamos años aplicando.
• En microservicios, una sesión vive en un servidor y una cookie vive en un dominio, lo que complica compartir ese estado entre tantos servicios separados.
• No escalan bien: más usuarios significa más sesiones abiertas y más consumo de memoria, casi siempre delegado a otro servicio con costo asociado.

No es que sea imposible resolverlo, se ha hecho durante años. Pero no es nada fácil ni elegante en contextos actuales.

¿Cómo cambia el flujo cuando usas JSON Web Tokens?

El arranque es idéntico: el usuario manda su nombre y contraseña en un request de tipo basic y de forma segura. El servidor confirma que existe y que la contraseña coincide [04:15].

La diferencia llega justo después. En lugar de crear una sesión, el servidor firma un JSON Web Token y se lo entrega al cliente, normalmente dentro de una cookie segura o directamente en la respuesta. A partir de ahí, el cliente usa ese token para pedir recursos al servidor.

¿Qué ventaja tiene un JWT frente a una sesión? El servidor no guarda estado: solo verifica que el token sea válido mediante un algoritmo, y el propio token transporta los permisos del usuario sin consultar la base de datos en cada request.

¿Qué problemas resuelve el token frente a la sesión?

Las Single Page Apps ya no dependen del servidor para conocer su estado, porque el token viaja con las autorizaciones dentro. El backend atiende múltiples clientes sin preocuparse por escalar sesiones ni consumir memoria adicional.

Y aquí viene un detalle clave: con sesiones, cada vez que el usuario pide permisos el sistema suele consultar la base de datos para verificarlos. Con JWT, esa información ya viaja firmada dentro del token, así que el cliente sabe qué puede hacer sin preguntar.

¿Cuándo conviene cada enfoque?

Las sesiones tienen una implementación robusta que ha funcionado por años, pero en contextos modernos muestran desventajas claras frente a microservicios, SPAs y REST APIs [06:40].

Los tokens son una solución efectiva, aunque exigen cuidado en cómo se implementan y, sobre todo, dónde se almacenan en el cliente. Ese punto de almacenamiento seguro es el que define si el sistema queda expuesto o protegido.

Un ejercicio útil: piensa en qué casos usarías tokens sin dudar y en cuáles preferirías sesiones. Comparte tu opinión en los comentarios y revisa qué se está usando hoy en distintos stacks. En la siguiente clase entras a la práctica de firmar un JSON Web Token con firma simétrica y asimétrica.