Keycloak 26.6.3 en pymes: tokens, WebAuthn y corte

La versión corrige fallas de seguridad. Cómo preparar staging, roles, base, backup y pruebas de corte antes de actualizar identidad en producción.

ULTIMA MILLA · Técnico · 5 de jun de 2026 · 4 min de lectura

Un usuario que conserva tokens después de perder un rol ya cambió el riesgo antes de que aparezca un incidente. Keycloak 26.6.3 salió el 4 de junio con correcciones de seguridad que una pyme puede probar sin adivinar. En una clínica privada de Godoy Cruz, la tarea es revisar sesiones, credenciales WebAuthn y clientes OIDC; esta guía muestra el flujo de actualización, permisos, base y prueba de corte.

Dónde aparece el riesgo de identidad

La publicación oficial de Keycloak 26.6.3 lista dieciséis correcciones de seguridad. Entre ellas aparecen token exchange, WebAuthn, introspección OIDC, CORS, grupos y endpoints de cuenta. Para gerencia, eso se traduce en una pregunta concreta: qué usuario conserva acceso después de un cambio administrativo. El dato global corrige la escala del problema. GitHub informó en su Octoverse que un desarrollador nuevo se suma a GitHub cada segundo, mientras la encuesta de Stack Overflow 2024 ubicó a PostgreSQL con 49% de uso. Identidad y base abierta ya no son piezas raras para una pyme; son infraestructura común que necesita pruebas comunes. La factura recurrente del proveedor de licencias muertas aparece cuando cada sistema mantiene usuarios propios. En la clínica, una pulsera de admisión sin imprimir quedó sobre el mostrador porque el módulo de turnos abrió y el de facturación rechazó la sesión. El detalle no importaba por la pulsera: importaba porque dos sistemas leyeron identidades distintas.

Cómo funciona por dentro

El flujo empieza con el usuario que pide acceso a una aplicación. Keycloak recibe usuario, contraseña, factor o credencial WebAuthn, consulta el realm y entrega tokens OIDC o SAML con roles. PostgreSQL guarda realms, clientes, usuarios, grupos, eventos y configuración persistente. La aplicación recibe el token y decide qué pantalla abre según permisos. El administrador carga grupos y clientes; seguridad revisa políticas de contraseña, sesiones, revocación y rotación. El tablero de eventos muestra inicio de sesión, fallo, renovación de token y cambio de rol. El backup copia la base y la configuración exportada; la prueba restaura el realm en staging y confirma que los clientes siguen validando tokens. La actualización se prueba en cinco pasos: levantar staging con copia de base, aplicar Keycloak 26.6.3, revisar migraciones, ejecutar login de usuarios reales de prueba y cortar una sesión activa. Si la sesión revocada sigue entrando, la actualización queda detenida. La documentación de administración de Keycloak ayuda a ordenar realms, grupos y clientes antes de correr la actualización. La guía de OIDC separa autorización, token, introspección y cierre de sesión. Esa separación permite armar pruebas que una gerencia entiende: usuario dado de baja, rol cambiado, token rechazado y evento guardado.

Qué se instala o configura primero

La pila mínima usa Keycloak 26.6.3, PostgreSQL 17, proxy HTTPS, backup de base, exportación de realm, monitoreo de logs y un ambiente de staging. Un despliegue chico con 8 a 20 aplicaciones queda entre USD 110 y USD 240 mensuales si incluye servidor, copia externa y alertas. Con dólar vendedor de ARS 1.458, el rango mensual va de ARS 160.380 a ARS 349.920. El primer entregable verificable es un realm con tres grupos, dos clientes OIDC, una política WebAuthn, exportación de configuración y prueba de revocación. La implementación lleva 30 a 60 horas cuando ya existe inventario de aplicaciones; sube si cada sistema usa reglas propias de usuario. El inventario inicial se arma con columnas concretas: aplicación, URL de redirección, responsable, tipo de cliente, roles que consume, grupo dueño y contacto de soporte. Cada fila se prueba con un login y una baja. El archivo queda versionado y firmado por IT, porque un cliente OIDC mal declarado puede abrir una puerta que ningún tablero muestra a tiempo. UMSA puede ordenar el trabajo en dos entregas: inventario de clientes y prueba de corte. La primera lista aplicaciones, redirect URIs, roles y responsables. La segunda demuestra que una baja, un cambio de rol y una revocación se reflejan en la aplicación correcta. La salida también se define al comienzo. El cliente debe poder exportar realms, políticas, clientes y grupos, junto con un instructivo de restauración. Esa copia no reemplaza el backup de PostgreSQL; lo acompaña con una lectura humana. Cuando cambia el proveedor, el nuevo equipo necesita saber qué significa cada rol antes de tocar la base.

Dónde se rompe y cómo probarlo

El primer riesgo es el redirect URI abierto. La señal aparece cuando un cliente acepta una URL que no pertenece a la aplicación. La prueba intenta login con dos URLs válidas y una falsa; el cliente debe rechazar la falsa. El segundo riesgo es la sesión que sobrevive a una baja. La señal aparece cuando un usuario revocado entra con token viejo. La prueba revoca el usuario, intenta renovar token y consulta una pantalla protegida. El tercer riesgo es la credencial WebAuthn sin validación suficiente. La señal aparece cuando una credencial queda asociada a un usuario equivocado o a un flujo incompleto. La prueba registra, revoca y vuelve a registrar una llave con auditoría de eventos. El cuarto riesgo es el backup de base sin exportación de realm. La señal aparece cuando PostgreSQL vuelve y el equipo no puede explicar clientes, roles o políticas. La prueba restaura base y exportación, inicia sesión y valida un token con el endpoint OIDC. La identidad queda sana cuando la baja se ve antes que el reclamo.