JWT frente a autenticación por sesión

Los JWT y las sesiones del lado del servidor son formas habituales de mantener autenticados a los usuarios tras el login. La diferencia está en dónde la aplicación almacena el estado de confianza.

Las sesiones guardan la mayor parte del estado en el servidor. Los JWT llevan claims firmados en el propio token.

Cómo funcionan las sesiones del lado del servidor

Con una sesión, el navegador suele guardar un ID de sesión opaco en una cookie. El servidor busca ese ID en una base de datos, caché o almacén de sesiones.

Este modelo es sólido cuando necesitas:

• Cierre de sesión y revocación inmediatos.
• Control centralizado de sesiones.
• Autenticación sencilla en el navegador basada en cookies.
• Credenciales pequeñas en el cliente.
• Cambios de rol gestionados por el servidor.

La contrapartida es que cada petición necesita acceso al estado de la sesión.

Cómo funciona la autenticación JWT

Con autenticación JWT, el cliente envía un token firmado. La API verifica la firma y lee claims como subject, issuer, audience y expiración.

Este modelo es útil cuando necesitas:

• APIs consumidas por varios servicios.
• Verificación stateless en el edge o en la capa de servicio.
• Access tokens de corta duración de un proveedor de identidad.
• Claims que viajan entre sistemas.
• Flujos de autenticación móvil o servicio a servicio.

La contrapartida es que la revocación y la frescura de los claims requieren un diseño cuidadoso.

La revocación es la gran diferencia

Las sesiones son más fáciles de revocar porque el servidor es dueño del estado. Elimina o invalida la sesión y la siguiente petición falla.

Los JWT son más difíciles de revocar si son de larga duración. Mitigaciones habituales incluyen access tokens de corta vida, refresh tokens, comprobaciones de versión del token, listas de denegación para casos de alto riesgo y revalidar permisos en la aplicación.

Las apps de navegador suelen combinar ambas ideas

Muchos sistemas en producción combinan patrones:

• El navegador tiene una cookie HTTP-only segura.
• El backend mantiene estado de refresh o sesión.
• Las APIs reciben access tokens JWT de corta duración.
• La autorización sensible sigue comprobando datos del lado del servidor.

La elección no siempre es binaria.

Guía de depuración

Para flujos JWT, inspecciona claims con Decodificador JWT y convierte exp, iat y nbf con Conversor de timestamp UTC.

Para flujos de sesión, depura la configuración de cookies, la disponibilidad del almacén de sesiones, atributos domain/path, el comportamiento SameSite y la invalidación del lado del servidor.

Regla práctica

Usa sesiones cuando el control centralizado y la simplicidad en el navegador importan más. Usa JWT cuando los claims firmados deben moverse entre APIs y servicios. Mantén los tokens de corta duración, verifica cada regla de confianza y evita poner secretos en cualquiera de los dos.