Tema 7
Autenticar correctamente al usuario es solo el comienzo. Después del login, el sistema debe mantener un estado de confianza durante un tiempo y bajo ciertas condiciones. Esa etapa, que parece operativa, es una de las superficies más sensibles del control de acceso. Una sesión mal diseñada puede anular por completo una autenticación fuerte.
En la mayoría de las aplicaciones, el usuario no vuelve a autenticarse en cada clic. El sistema crea un mecanismo que representa la sesión autenticada y lo reutiliza para reconocer solicitudes posteriores. Esa comodidad es necesaria, pero introduce un problema central: si alguien roba o manipula ese artefacto de sesión, puede actuar como el usuario sin necesidad de conocer su contraseña ni completar MFA.
Por eso la seguridad de acceso no termina en el login. Continúa en la emisión, el transporte, el almacenamiento, la expiración y la revocación de la sesión o del token que representa al usuario autenticado.
Este tema estudia esa capa intermedia entre autenticación y autorización cotidiana. Allí aparecen conceptos como cookies, session IDs, access tokens, refresh tokens, expiración absoluta, expiración por inactividad y reautenticación.
Una sesión es una representación temporal del estado autenticado de un sujeto. Le permite al sistema reconocer que una serie de solicitudes pertenece a una identidad ya verificada, sin repetir el proceso completo de autenticación en cada interacción.
La sesión no es la identidad misma ni la credencial original. Es un estado derivado, con alcance y duración limitados. Esa distinción importa porque una sesión debería poder expirar, revocarse o elevar su exigencia de seguridad sin afectar necesariamente a la identidad subyacente.
Muchas implementaciones fuertes de autenticación fallan después del login porque el sistema trata la sesión como un detalle menor. Sin embargo, el artefacto de sesión suele convertirse en el objetivo más práctico para el atacante.
Un secuestro de sesión puede ocurrir por varios caminos:
El resultado es grave porque, desde la perspectiva del sistema, el atacante ya “parece” un usuario autenticado legítimo.
En términos generales, existen dos grandes enfoques:
Cada modelo tiene ventajas y compromisos. Las sesiones stateful facilitan invalidación central y control fino del ciclo de vida. Los tokens autoportantes pueden simplificar escalabilidad y desacoplar servicios, pero hacen más compleja la revocación inmediata si no se diseñan mecanismos complementarios.
En una sesión clásica basada en servidor, el cliente recibe un identificador aleatorio sin significado directo. Ese identificador apunta a un registro en backend donde el sistema conoce el estado autenticado del usuario.
En un modelo basado en tokens, el cliente suele portar un artefacto firmado o estructurado que la aplicación o API valida en cada solicitud. En algunos casos el token contiene claims; en otros, solo referencia un estado externo.
| Enfoque | Qué porta el cliente | Ventaja típica | Desafío típico |
|---|---|---|---|
| Sesión stateful | Un identificador de sesión | Revocación central simple | Necesidad de almacenamiento y sincronización del estado |
| Token stateless | Un token validable por firma o reglas locales | Escalabilidad y menor dependencia del storage central | Revocación y control fino más difíciles |
En aplicaciones web tradicionales, las cookies son uno de los mecanismos más frecuentes para transportar el identificador de sesión. No son inseguras por definición; de hecho, bien configuradas pueden ser una opción adecuada. El problema aparece cuando se usan sin atributos de protección correctos.
Una cookie de sesión debería evaluarse al menos en estos aspectos:
Dos amenazas clásicas aparecen inmediatamente cuando se habla de cookies de sesión:
Estos riesgos no se resuelven solo con un atributo. La defensa completa suele combinar:
En aplicaciones modernas aparece a menudo la tentación de guardar tokens en lugares cómodos para el frontend, como `localStorage` o `sessionStorage`. El problema es que cualquier XSS exitoso puede acceder a esos valores y reutilizarlos.
Eso no significa que siempre esté prohibido usar esos mecanismos, pero sí que su uso debe evaluarse con criterio. Cuando el riesgo es alto, conviene preferir diseños donde el artefacto más sensible no esté expuesto trivialmente a scripts del cliente.
La pregunta correcta no es “¿dónde es más fácil guardar el token?”, sino “¿qué superficie de robo estoy habilitando si el frontend es comprometido?”.
En arquitecturas basadas en tokens suele diferenciarse entre dos artefactos:
Esta separación ayuda a limitar exposición. Si un access token es robado y su vida es corta, el daño temporal puede reducirse. Pero si el refresh token se expone, el atacante puede prolongar el acceso durante más tiempo. Por eso el refresh token suele requerir un nivel aún mayor de protección.
Una sesión segura no debería durar indefinidamente. En general se combinan dos tipos de expiración:
La combinación elegida depende del riesgo y de la naturaleza del sistema. Un portal bancario no debería manejar los mismos tiempos que una intranet informativa. La duración debe equilibrar usabilidad y exposición operativa.
No alcanza con fijar una duración. También importa cómo se renueva una sesión. Un patrón común es emitir access tokens de corta vida y renovarlos mediante refresh token. En otros casos, el servidor rota el identificador de sesión tras ciertos eventos.
La rotación es útil porque reduce la ventana de explotación y limita reutilización de artefactos antiguos. En especial conviene considerar rotación ante:
Un buen sistema necesita poder invalidar sesiones antes de su expiración natural. Esto importa cuando el usuario cierra sesión, cambia su contraseña, reporta un dispositivo robado o se detecta actividad sospechosa.
En modelos stateful la revocación suele ser más directa porque el servidor controla centralmente el estado. En modelos con tokens más autónomos, la revocación requiere mecanismos adicionales: listas de deny, versionado de sesión, introspección o tiempos de vida muy cortos combinados con rotación.
Un error común es implementar un “logout” solo del lado del cliente, eliminando el token visible pero dejando vigente el estado en el backend o en otros dispositivos.
La fijación de sesión ocurre cuando un atacante logra que la víctima use un identificador de sesión conocido por él. Si luego la víctima se autentica dentro de esa sesión, el atacante podría reutilizar ese mismo identificador para tomar control.
La defensa principal es regenerar el identificador de sesión después del login y tras eventos relevantes de seguridad. Nunca debería mantenerse intacto el mismo identificador no autenticado una vez que la identidad queda validada.
El secuestro de sesión ocurre cuando un atacante obtiene el artefacto que representa la sesión válida y lo reutiliza para hacerse pasar por el usuario. Puede lograrlo por robo de cookies, XSS, malware, fuga de logs, almacenamiento inseguro o errores de transporte.
Una vez obtenido el identificador o token, el sistema puede no distinguir entre la víctima y el atacante si no existen señales adicionales de contexto, revocación o revalidación. Por eso la protección del artefacto de sesión es tan importante como la protección de la contraseña.
No todas las acciones deberían depender únicamente de una sesión vieja aún válida. Para operaciones sensibles conviene exigir una revalidación reciente o un paso adicional, por ejemplo:
Esto reduce el impacto de una sesión robada o dejada abierta en un equipo compartido.
En muchos entornos resulta útil permitir al usuario o al administrador ver sesiones activas: dispositivo, ubicación aproximada, fecha de inicio, último uso y posibilidad de cerrarlas remotamente. Esta capacidad mejora la trazabilidad y ayuda a responder ante sospechas de compromiso.
También conviene decidir la política sobre sesiones concurrentes: si se permiten múltiples dispositivos, cuántos, y qué eventos fuerzan cierre global.
Una sesión no debería tratarse como una autorización inmutable hasta su vencimiento. En enfoques modernos, el sistema observa si cambia algo relevante durante la vida de la sesión:
Ante estas señales, el sistema puede invalidar, limitar o elevar exigencia de autenticación. Esta lógica se alinea con enfoques de autenticación adaptativa y Zero Trust.
La seguridad de acceso no termina cuando el usuario inicia sesión. En muchos sistemas, el verdadero riesgo empieza después, cuando el estado autenticado debe mantenerse, renovarse y revocarse correctamente. Una buena gestión de sesiones reduce la ventana de abuso y mantiene coherencia entre autenticación, riesgo y operación.
En el próximo tema entraremos en autorización: permisos, políticas y cómo se toman decisiones sobre qué está permitido para una identidad autenticada.