¿Caducan las sesiones de tus aplicaciones autoalojadas cuando deberían? Guía práctica de evaluación

Por qué importa el comportamiento de las sesiones después de iniciar sesión

La autenticación confirma que un usuario ha iniciado sesión. La sesión es lo que permite a la aplicación reconocerlo mientras navega entre páginas o vuelve a la aplicación. Si una sesión sigue siendo válida más tiempo del previsto, alguien con acceso al navegador o a una credencial de sesión copiada podría seguir usando la cuenta.

Configurar un tiempo de espera no demuestra que todas las vías pertinentes caduquen como deberían. El cierre de sesión, un cambio de contraseña, la desactivación de una cuenta y el inicio de sesión único pueden involucrar distintas partes del sistema. Evalúa el comportamiento como un ciclo de vida, no como un único ajuste.

OWASP recomienda aplicar la caducidad de las sesiones en el servidor e invalidar una sesión cuando el usuario cierra sesión ([Session Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html)). NIST indica que las cookies de sesión deberían caducar al mismo tiempo que el periodo de validez de la sesión o poco después ([Session Management](https://pages.nist.gov/800-63-4/sp800-63b/session/)). Estas recomendaciones no demuestran que todas las aplicaciones ofrezcan los mismos controles ni que todos los flujos deban tener un resultado universalmente obligatorio.

Distingue entre el inicio de sesión, la duración de la sesión, el tiempo de espera por inactividad y los dispositivos recordados

Antes de revisar los ajustes, utiliza términos coherentes. El inicio de sesión es el paso de autenticación. Una sesión es el reconocimiento continuado de ese inicio de sesión por parte de la aplicación. La sesión puede representarse o mantenerse mediante más de un mecanismo, por lo que la fecha de caducidad que muestra una cookie del navegador, por sí sola, quizá no permita saber si el servidor sigue aceptando la sesión.

Un tiempo de espera por inactividad limita una sesión tras un periodo sin actividad. Una duración máxima de la sesión, a veces llamada duración absoluta, limita cuánto tiempo puede seguir siendo válida una sesión, independientemente de la actividad. No des por sentado que la actividad reinicia el límite absoluto ni que un ajuste llamado «tiempo de espera de sesión» significa una cosa concreta: consulta la documentación de la aplicación y prueba su comportamiento.

Una opción de «recordarme» o de dispositivo recordado puede cambiar la experiencia del usuario en una visita posterior. Averigua si restaura una sesión, evita algunos pasos de autenticación o hace otra cosa en esa aplicación concreta. Registra su comportamiento por separado, en vez de considerarla el mismo control que el tiempo de espera por inactividad.

Define requisitos en función de los flujos reales y los riesgos

Elige los requisitos según el uso de la aplicación y lo que podría quedar expuesto si una sesión está desatendida o sigue siendo válida. Una estación de trabajo compartida, el acceso a registros empresariales confidenciales o la posibilidad de realizar cambios importantes pueden requerir expectativas distintas de las de una aplicación que se usa brevemente en un dispositivo privado.

Antes de probar, anota qué debería ocurrir tras un periodo de inactividad, al alcanzar la duración máxima de una sesión y después del cierre de sesión explícito. Define también el resultado que necesitas tras un cambio de contraseña, la desactivación de una cuenta o un evento de SSO; no supongas que la aplicación o el proveedor de identidad se encargarán automáticamente.

Las directrices citadas no establecen un único valor de tiempo de espera aplicable a todas las aplicaciones y flujos. Toma la decisión de forma explícita como una elección de seguridad y usabilidad, y documenta cualquier excepción, como un flujo en el que los usuarios necesiten mantener abierta una sesión para una tarea de larga duración.

• ¿A qué datos o acciones se puede acceder y qué permitiría una sesión desatendida?
• ¿Es probable que los usuarios trabajen en dispositivos compartidos o desatendidos?
• ¿Qué deberían ser el periodo de inactividad y la duración máxima aceptables?
• ¿Qué eventos deberían poner fin al acceso: cierre de sesión, cambio de contraseña, desactivación de la cuenta o un cambio en el proveedor de identidad?
• ¿Existe una opción para recordar dispositivos y su comportamiento es aceptable para tu caso de uso?

Consulta la documentación de la aplicación para conocer los controles disponibles

Busca en la documentación oficial términos como caducidad de sesión, tiempo de espera por inactividad, duración máxima, cierre de sesión, revocación de sesiones, dispositivos recordados y SSO. Consulta la documentación de la aplicación y la versión que utilizas. No deduzcas que existe una función porque un producto similar tenga una función con un nombre parecido.

Registra si cada control se puede configurar, dónde se configura y si la documentación describe su aplicación en el servidor. El ajuste de caducidad de una cookie y la regla de validez de una sesión en el servidor son comprobaciones relacionadas, pero una no debe considerarse prueba de la otra. Si un flujo no está descrito, márcalo como desconocido para comprobarlo en una prueba o consultarlo con el proveedor o responsable de mantenimiento.

La recomendación de OWASP sobre la caducidad en el servidor y la invalidación al cerrar sesión, y la de NIST sobre la caducidad de las cookies respecto al periodo de validez de la sesión, sirven como referencias para esas comprobaciones. Las fuentes no especifican qué debería ocurrir tras cambios de contraseña, desactivaciones de cuentas, la duración máxima o las sesiones del proveedor de identidad; verifica esos casos en tu aplicación.

• Anota qué significa cada ajuste de tiempo de espera, incluido si la actividad lo reinicia.
• Busca una forma documentada de finalizar o revocar sesiones activas y registra su alcance.
• Comprueba si el comportamiento difiere entre cuentas locales y usuarios de SSO.
• Conserva el título y la versión o fecha de la documentación, si están disponibles, y la fecha en que la revisaste.

Realiza pruebas prácticas del ciclo de vida

Siempre que sea posible, utiliza una cuenta de prueba y un entorno que no sea de producción. Si tienes que probar en producción, planifica el trabajo para evitar interrumpir a otros usuarios o cambiar inesperadamente el acceso a cuentas reales. No guardes datos confidenciales en la cuenta de prueba ni incluyas credenciales de sesión u otros secretos en capturas de pantalla o notas compartidas.

Para probar la inactividad, inicia sesión, deja la aplicación sin usar durante el intervalo configurado y luego intenta abrir una página protegida o realizar una acción inocua. Comprueba por separado la duración máxima: mantén la sesión activa según lo requiera el plan de pruebas y verifica si termina al alcanzar el límite indicado. Registra el tiempo transcurrido y lo que ve el usuario.

Para probar el cierre de sesión, cierra sesión e intenta volver a una página protegida usando el mismo contexto del navegador. OWASP recomienda que el cierre de sesión invalide la sesión; comprueba si la sesión anterior aún permite acceder a contenido protegido. Una redirección a la página de inicio de sesión no es concluyente si el contenido sigue siendo accesible por otra ruta.

Prueba el cambio de contraseña y la desactivación de la cuenta como eventos separados. Comprueba si las sesiones existentes siguen funcionando y si el resultado coincide con el requisito que definiste. Las fuentes citadas no establecen un resultado universalmente obligatorio para estos casos, así que documenta el comportamiento observado en vez de darlo por sentado.

Utiliza una acción de prueba inocua y autorizada para confirmar el estado del acceso. Si el resultado no está claro, repite la prueba en una sesión limpia del navegador y consulta la documentación de la aplicación o su canal de soporte.

Repite las comprobaciones para SSO y las cuentas locales

Si la aplicación admite tanto el inicio de sesión local como el inicio de sesión único, prueba cada método por separado. La aplicación y el proveedor de identidad pueden tener sesiones independientes; poner fin a una no demuestra por sí solo que la otra también haya terminado. Del mismo modo, cerrar sesión en una aplicación no necesariamente cierra la sesión del usuario en el proveedor de identidad.

Para SSO, registra la secuencia y el resultado del cierre de sesión en la aplicación y en el proveedor de identidad. Comprueba también qué ocurre cuando el usuario vuelve a la aplicación y cuando intenta usar una página que ya estaba abierta. Para las cuentas locales, repite las pruebas pertinentes sin suponer que se aplica el comportamiento de SSO.

Si el proveedor de identidad o la aplicación ofrece controles de revocación de sesiones, documenta qué afirman revocar y confirma el efecto en una prueba. Si el comportamiento no está documentado o no se puede probar, anótalo como pendiente en vez de interpretar una redirección aparentemente satisfactoria como prueba.

Registra los resultados en una matriz de sesiones

Una matriz breve convierte las comprobaciones puntuales en pruebas operativas repetibles. Mantén el resultado esperado separado del observado: el primero refleja tu política y el segundo, lo que hizo la aplicación durante la prueba.

Incluye la aplicación y su versión, el método de autenticación, la fecha de la prueba, la configuración pertinente, la cuenta de prueba, los pasos, el tiempo transcurrido cuando corresponda, el resultado observado y el estado: aprobado, fallido o sin resolver. Anota la documentación consultada y la próxima acción para cualquier resultado sin resolver. No registres contraseñas, tokens de sesión ni otras credenciales.

Repite la matriz después de cambios importantes en la configuración de la aplicación, la configuración de autenticación o la implementación. El calendario de pruebas es una decisión operativa de tu equipo; las fuentes citadas no establecen un intervalo de repetición.

• Inactividad y duración máxima: límite esperado, intervalo probado y disponibilidad del acceso protegido al finalizar.
• Cierre de sesión: invalidación esperada y resultado al reutilizar el mismo contexto del navegador.
• Cambio de contraseña y desactivación de cuenta: efecto esperado en las sesiones existentes y resultado observado.
• SSO e inicio de sesión local: método probado y sesión del sistema involucrada.
• Controles no documentados o resultados no verificados: estado y próxima acción.

Asigna responsabilidades entre la aplicación, el proveedor de identidad y el alojamiento

No des por sentado que una sola parte controla todo el ciclo de vida de las sesiones. Asigna cada comportamiento esperado al componente que puede configurarlo o verificarlo en tu implementación. Las fuentes citadas ofrecen orientación sobre caducidad e invalidación al cerrar sesión, pero no distribuyen responsabilidades entre la aplicación, el proveedor de identidad y el alojamiento.

El responsable de la aplicación debería documentar la política de acceso, verificar el comportamiento de la aplicación y decidir cómo gestionar las brechas pendientes. Para los flujos de SSO, coordínate con el administrador del proveedor de identidad para entender sus controles de sesiones y cuentas y, a continuación, prueba la experiencia combinada. Deja explícita la división de tareas.

Airbip ofrece la implementación gestionada de las aplicaciones del catálogo como cargas de trabajo de Docker en servidores en la nube de Airbip, con enrutamiento automatizado y certificados TLS mediante Traefik y Let’s Encrypt, además de gestión del ciclo de vida de los servicios y copias de seguridad configurables. Estas capacidades de infraestructura no determinan, por sí solas, qué hace una aplicación cuando caduca una sesión o se desactiva una cuenta. Confirma el comportamiento en la aplicación y acuerda quién se ocupa de cada tarea operativa.

Si tu organización necesita un control de sesiones que la aplicación no ofrece, no consideres la gestión de la infraestructura un sustituto, a menos que un control documentado y probado cumpla el requisito. Evalúa si debes cambiar la configuración, añadir un control adecuado, elegir otra aplicación o modelo de implementación, o aceptar el riesgo residual.

• Indica quién es responsable de la política de tiempos de espera y quién aprueba las excepciones.
• Identifica quién configura y prueba el comportamiento de las sesiones en la aplicación.
• Para SSO, identifica al administrador del proveedor de identidad y qué comportamientos puede confirmar.
• Documenta por separado las tareas de alojamiento y las relativas al acceso a la aplicación y la gestión de cuentas.