Es fácil pensar que, al conectar inerit y el blog al mismo Keycloak, el inicio de sesión fluirá de manera natural. Sin embargo, compartir el servidor de autenticación es una cosa, y que cada servicio cree su propio estado de inicio de sesión es otra distinta.
Durante las tareas realizadas en noviembre de 2026, iniciar sesión en un lado no implicaba la continuidad de la autenticación en el otro, lo que requería una reautenticación. Posteriormente, se abordó la interconexión bidireccional del inicio de sesión, los permisos por servicio, la prevención del reinicio inmediato de sesión tras un cierre explícito y la migración de cuentas existentes. Este artículo recoge las lecciones de diseño obtenidas de los registros de trabajo de aquel momento. No se han vuelto a verificar los resultados bajo el estado operativo actual.
La autenticación central y las sesiones de servicio son cosas distintas
Aunque un usuario esté autenticado en el servidor de autenticación, es posible que un servicio visitado por primera vez aún no haya verificado dicho resultado. El servicio debe comprobar el estado de autenticación, someterlo a las validaciones necesarias y crear su propio estado de inicio de sesión. Esto es diferente a leer directamente las cookies de otro servicio.
Al analizar fallos, también es necesario separar las preguntas:
- ¿Existe una sesión SSO válida en el servidor de autenticación?
- ¿El nuevo servicio ha iniciado la verificación de autenticación?
- ¿La validación de la respuesta y el vínculo con la cuenta existente han finalizado con éxito?
- ¿El usuario y los permisos son los permitidos por el servicio?
Keycloak distingue entre la sesión de usuario SSO y la sesión del cliente, además de poder existir sesiones propias de la aplicación. Si se tratan las políticas de expiración como un único bloque, resulta difícil identificar en qué límite se ha interrumpido el estado. Configuración de expiración de sesiones de Keycloak
El inicio de sesión automático y el cierre forzado son políticas distintas
Redirigir al usuario a la pantalla de autenticación cada vez que abre una página pública difiere de mantener el estado de inicio de sesión únicamente cuando ya existe una autenticación previa. Se trata de políticas diferentes.
Por ejemplo, login-required y check-sso del adaptador JavaScript de Keycloak ofrecen experiencias de acceso distintas. Esto es solo un ejemplo para ilustrar la diferencia y no implica que inerit haya utilizado dichas opciones en aquel momento. Asimismo, prompt=none en OpenID Connect solo solicita que el procesamiento se realice sin interacción, pero no elimina la autenticación ni el consentimiento. Si es necesario, se devuelve un resultado como login_required. Reintentar esto sin condiciones puede provocar un flujo repetitivo entre el servidor de autenticación y el servicio. Adaptador JavaScript de Keycloak, Solicitud de autenticación de OpenID Connect
La verificación silenciosa de autenticación basada en iframe también se ve afectada por las restricciones de cookies de terceros de los navegadores. Que funcione en un navegador no garantiza un comportamiento idéntico en todos los entornos.
La autenticación y la aprobación de uso son conceptos separados
La autenticación central verifica la identidad del usuario, pero no determina automáticamente si se permite su uso de un servicio específico. Incluso una cuenta aprobada en un servicio puede estar sujeta a condiciones diferentes en otro. En tales casos, es preferible informar claramente del estado de espera de aprobación o de acceso restringido, en lugar de volver a solicitar la contraseña.
Los permisos pueden representarse mediante roles de cliente en Keycloak o gestionarse dentro del propio servicio. Independientemente de la opción elegida, deben verificarse no solo en la presentación visual, sino también en los componentes que procesan solicitudes protegidas. El consentimiento de usuario según el protocolo y la aprobación de uso por criterios operativos del servicio son conceptos diferentes. Roles de cliente en Keycloak
El cierre de sesión incluye la intención del usuario
Aunque se haya eliminado la sesión del servicio, es posible que la sesión SSO central persista. Si la página inicia automáticamente un nuevo inicio de sesión en ese instante, el usuario verá una pantalla autenticada inmediatamente después de haber pulsado el botón de cierre de sesión.
En primer lugar, debe definirse si el cierre afecta únicamente al servicio actual o también a la sesión central. Si se trata de un cierre a nivel de servicio, también debe determinarse durante cuánto tiempo se mantiene la supresión del inicio de sesión automático y cómo se desactiva ante una solicitud explícita de inicio. Este estado está orientado a la experiencia de usuario y no sustituye las verificaciones de autenticación ni de autorización en el servidor.
Asimismo, no debe asumirse que el cierre central elimina de inmediato las sesiones y pantallas de otros servicios. OpenID Connect define por separado RP-Initiated Logout para solicitar el cierre al servidor de autenticación y Back-Channel Logout para gestionar notificaciones entre servidores. El método de aplicación real debe verificarse según los requisitos e implementaciones de cada servicio.
Migración de cuentas y verificación
En la migración de cuentas existentes no basta con comprobar si el inicio de sesión funciona correctamente. Es necesario verificar que la propiedad de los datos y el estado de aprobación por servicio se vinculen a la cuenta correcta, y que no existan cuentas ambiguas o duplicadas. Según OpenID Connect, la estabilidad del identificador se aborda mediante la combinación de iss e sub. No obstante, la existencia de dicho identificador no demuestra automáticamente el vínculo con una cuenta local preexistente. Identificadores de OpenID Connect
Durante la verificación, es más importante seguir las transiciones de estado que confirmar un único inicio de sesión correcto.
- ¿El flujo de autenticación previsto funciona al desplazarse entre servicios, independientemente del punto de partida?
- ¿Un usuario no autenticado queda atrapado en bucles de inicio de sesión al visualizar pantallas públicas?
- ¿Se muestra la orientación adecuada cuando el usuario está autenticado pero carece de aprobación de uso?
- ¿Se mantiene la política prevista tras un cierre de sesión explícito, incluso al actualizar o volver a visitar la página?
- ¿Es posible recuperarse cuando la expiración de la sesión central y la del servicio difieren?
- ¿Se conservan correctamente los datos y permisos de las cuentas preexistentes?
La esencia del SSO no consiste únicamente en reducir a una vez la pantalla de inicio de sesión. Debe decidirse en qué componente gestionar la identidad demostrada por el servidor de autenticación, las sesiones y permisos de cada servicio y la intención de cierre de sesión del usuario.
