Unificar la caducidad del acceso entre servicios: renovación y reautenticación

Compartir una cuenta no hace idénticas las sesiones de cada aplicación y del proveedor de identidad. Este caso alinea las reglas sin publicar destinos ni duraciones.

Comparar la misma solicitud antes y después del vencimiento

Use una duración corta en pruebas. Ejecute por separado login explícito, navegación y actualización en segundo plano, y compare el vencimiento del servidor. Tras vencer, pruebe la misma operación en interfaz y API, verificando reautenticación y rechazo del acceso. Separe esta prueba del comportamiento prolongado en producción.

OWASP：Diseño y pruebas del vencimiento de sesión

Identificar cada plazo

Inventariar por separado la sesión del proveedor, la sesión de la aplicación y la cookie. Caducidad absoluta, inactividad y rotación del identificador son controles distintos. Rotar un identificador no exige ampliar su vigencia.

Separar acceso explícito y tráfico habitual

El caso renueva el período aplicable tras un inicio explícito correcto, no por navegar, tráfico de fondo, renovación automática de tokens o rotación del identificador; conservan la caducidad original. Un clic o la llegada al callback no acreditan autenticación: verificar el resultado. Si se exige autenticación reciente, comprobar si reutilizar la sesión del proveedor satisface esa condición.

Comprobar la caducidad en el servidor

Una cookie más duradera no define lo que acepta el servidor. Revisar caducidad, revocación, cookie y restricciones del proveedor. Reglas uniformes no significan cookies compartidas ni cierre inmediato en todos los servicios.

Validar el momento de autenticación y la caducidad de la autoridad, limitando a ellos las sesiones de las aplicaciones. El contrato común valida sesiones; cada aplicación conserva sus permisos de negocio. Una pasarela con su propia cookie tiene otro límite que inventariar y auditar.

1. 1 Proveedor de identidad y callback Valide el resultado de autenticación y el context/state del callback. Iniciar sesión no concede por sí solo acceso a la aplicación.
2. 2 Aplicación, cookie y gateway Compruebe por separado la caducidad y revocación de la sesión del servidor, la cookie del navegador y la sesión del gateway.
3. 3 Permisos de cada servicio Cada aplicación verifica sus propios permisos. El tráfico normal y la actualización en segundo plano no amplían la caducidad ni implican un cierre de sesión global.

Separar configuración y comportamiento

Auditar código y ajustes por separado de las pruebas de inicio, límites de caducidad, acceso tras caducar y cierre. Revisar cómo se aplica la política a sesiones existentes y cómo páginas y API gestionan la caducidad. Registrar decisiones y horas, sin valores de sesión ni credenciales.

Alcance confirmado

El historial registra cambios, despliegues y herramientas para auditar diferencias. No se probaron el acceso de usuarios reales ni la espera hasta la caducidad efectiva en estos registros. No demuestra pruebas con tiempo real en todos los dispositivos ni toda la seguridad de revocación y reautenticación. Elegir plazos y verificaciones según la sensibilidad de datos y operaciones.

Consultar sesiones de OWASP y autenticación. Para otra capa, ver sesiones de Cloudflare. Las recomendaciones no afirman que todas las pruebas se completaran en este caso.

Actualización del 6 de octubre de 2026: continuidad de la autenticación y permisos de la aplicación

En el registro anonimizado de una mejora de autenticación se separaron la llegada al callback de OIDC, la validación del token, la continuación de la solicitud de autenticación original y los permisos para usar la aplicación. Si falta el contexto necesario para continuar, el flujo no lo presenta como un inicio de sesión correcto: devuelve un error seguro desde el que se puede reanudar. También valida el destino de retorno; iniciar sesión en una cuenta compartida no concede por sí solo permisos de negocio en cada aplicación.

El mismo contrato se comprueba al iniciar sesión y registrarse, al añadir o retirar proveedores de autenticación y en los mecanismos de recuperación. Los registros de cambios y despliegue no demuestran que todas las personas usuarias puedan iniciar sesión con todos los proveedores ni que se haya probado de principio a fin la conservación del último método de recuperación.

La activación de un segundo factor, el inicio de sesión en la plataforma de identidad, el paso por la puerta de acceso y una escritura protegida en la aplicación también se verifican por separado. Una prueba de escritura limitada no sustituye la comprobación de todos los flujos formales de OIDC ni demuestra que se rechace una cuenta desactivada. El registro, la configuración inicial, las pantallas de cambio y la API consultan las mismas reglas de entrada; las pruebas comprueban en conjunto los valores límite que se rechazan y los que se permiten. No se presenta una longitud concreta como norma universal.

También se separan las pantallas y las indicaciones del callback para iniciar sesión y registrarse. Ver una pantalla o una comprobación de salud no equivale a aceptar la creación real de una cuenta externa ni la concesión del consentimiento. Al retirar un proveedor se revisan en conjunto el botón, el callback, la configuración, las indicaciones y las pruebas, y después se comprueba si queda alguna ruta residual.