El futuro de Keycloak: las features experimentales y en preview que marcan hacia dónde va el proyecto
· IAM · IDPTrust
Cuando se habla de Keycloak, casi siempre se habla de lo que ya hace: login único, federación con Active Directory, autenticación multifactor. Pero hay otra conversación más interesante para quien tiene que planificar a medio plazo: ¿hacia dónde va el proyecto?
Esa respuesta está en las funcionalidades que Keycloak desarrolla en fase preview y experimental — versiones tempranas, todavía no recomendadas para producción, pero que anticipan lo que será estándar dentro de uno o dos años.
Este artículo las repasa una a una: qué son y por qué importan. (A fecha de este artículo, la última versión estable es la 26.6; algunas de estas funcionalidades llegan en la 26.7, todavía sin publicar.)
Una aclaración primero: ¿qué significa "experimental"?
Keycloak clasifica sus funcionalidades en tres niveles:
- Supported (soportada): lista para producción, con garantías de estabilidad y soporte.
- Preview (vista previa): funciona, pero puede cambiar de aquí a la versión final. No recomendada para producción.
- Experimental: en desarrollo activo, puede cambiar radicalmente o incluso desaparecer.
Las funcionalidades experimentales y en preview están desactivadas por defecto. Hay que habilitarlas explícitamente, y hacerlo en un entorno de producción sin entender las implicaciones es un error. Pero conocerlas es justo lo que permite diseñar una arquitectura de identidad que no se quede obsoleta pronto.
Si quieres el contraste, hace poco repasamos las cinco funcionalidades que la 26.6 llevó de preview a soporte completo: así se ve el camino completo, de lo experimental a lo sólido.
Veamos las más relevantes ahora mismo.
1. SCIM Realm API — gestión automática de usuarios mediante un estándar
(Experimental · disponible desde la versión 26.6)
Qué es: SCIM es un estándar para crear, actualizar y eliminar usuarios y grupos de forma automática entre plataformas. Con esta funcionalidad, Keycloak puede actuar como servidor SCIM: expone su gestión de usuarios y grupos a través del protocolo SCIM, de modo que un sistema externo pueda mantenerlos sincronizados sin intervención manual. En la práctica es "la Admin API de Keycloak, pero hablando SCIM".
Por qué importa: en muchas empresas la fuente de verdad de "quién es quién" no es Keycloak, sino el directorio corporativo o el sistema de RRHH (por ejemplo Microsoft Entra ID). Cuando alguien entra en la empresa, ese sistema debería poder darlo de alta en Keycloak automáticamente; cuando alguien se va, darlo de baja de inmediato — que es donde más riesgos de seguridad se acumulan. La SCIM Realm API permite justo eso: que ese sistema upstream provisione usuarios hacia Keycloak mediante un estándar, en lugar de crearlos a mano realm por realm.
El equipo de Keycloak ha priorizado la compatibilidad con Microsoft Entra ID, que es la integración más demandada — en ese escenario, Entra ID es quien provisiona y Keycloak quien recibe.
Conviene no confundir esto con el caso inverso: que Keycloak aprovisione usuarios hacia otras aplicaciones (correo, VPN, herramientas de tickets) actuando como cliente SCIM. Eso es un caso de uso distinto y no es lo que entrega esta funcionalidad hoy.
Disponible como experimental desde la versión 26.6. Anuncio oficial · Issue de seguimiento en GitHub (#46227).
2. AuthZEN — un lenguaje común para las decisiones de autorización
(Experimental · llega con la 26.7, aún sin publicar; disponible hoy solo en builds nightly)
Qué es: AuthZEN es un estándar nuevo de la OpenID Foundation que define una forma única de preguntar "¿puede esta persona hacer esta acción sobre este recurso?". A partir de la versión 26.7, Keycloak podrá actuar como el componente que responde esa pregunta (lo que técnicamente se llama un Policy Decision Point).
Por qué importa: hoy, cuando una empresa elige un sistema para gestionar permisos, su código de aplicación queda atado a ese sistema concreto. Cambiar de proveedor implica reescribir código. AuthZEN rompe esa dependencia: define un idioma común, de modo que cualquier aplicación puede preguntar a cualquier motor de autorización compatible sin cambiar nada. Es el fin del vendor lock-in en autorización.
Llegará como experimental con la versión 26.7 (todavía no publicada). Puedes probarlo hoy con las builds nightly de Keycloak. Anuncio oficial · Discusión técnica en GitHub (#45288).
3. OID4VCI — identidad descentralizada y wallets digitales
(Experimental · en desarrollo activo)
Qué es: OID4VCI (OpenID for Verifiable Credential Issuance) permite a Keycloak emitir credenciales verificables — el equivalente digital de un carné o un título que el usuario guarda en su propia wallet y puede presentar sin depender de quien lo emitió.
Por qué importa: es la base de la identidad descentralizada, el modelo hacia el que apuntan iniciativas como la cartera de identidad digital europea (EUDI Wallet). De hecho, la Comisión Europea exige a todos los estados miembro ofrecer esa wallet a sus ciudadanos para finales de 2026, y OID4VCI es el estándar técnico elegido para cumplirlo. En lugar de que cada servicio guarde tus datos, tú llevas tus credenciales contigo y decides cuándo y a quién las muestras. Que Keycloak se posicione aquí indica que el proyecto se toma en serio este futuro.
Sigue siendo experimental y en desarrollo activo dentro del grupo de trabajo OAuth SIG de Keycloak.
Issue de seguimiento en GitHub (#42889) · Discusión sobre la implementación (#45743) · Guía: emitir credenciales con OID4VCI.
4. Autenticación de cliente con OAuth SPIFFE — identidad para máquinas
(Preview · la especificación está en estado de borrador)
Qué es: SPIFFE es un estándar para dar identidad a workloads — es decir, a los propios servicios y máquinas, no a las personas. Permite que un servicio demuestre quién es sin usar contraseñas ni secretos almacenados.
Por qué importa: en arquitecturas modernas (microservicios, contenedores, zero-trust), no solo las personas necesitan autenticarse: los propios componentes del sistema hablan entre ellos constantemente y deben verificar su identidad mutuamente. SPIFFE resuelve esto sin secretos que gestionar y rotar, que son una fuente habitual de brechas de seguridad.
Permanece en preview porque la especificación todavía está en estado de borrador.
Issue de autenticación de clientes con SPIFFE/SPIRE (#41907) · Identity provider SPIFFE experimental (#42313).
5. CIMD para MCP — Keycloak en la era de los agentes de IA
(Experimental · disponible desde la versión 26.6)
Qué es: el Model Context Protocol (MCP) es el estándar emergente que permite a los agentes de IA conectarse a herramientas y datos externos. Desde finales de 2025, MCP requiere que el servidor de autorización cumpla con un formato llamado CIMD (OAuth Client ID Metadata Document). Keycloak ya incluye soporte experimental para ello.
Por qué importa: los agentes de IA que actúan en nombre de un usuario necesitan permisos: a qué pueden acceder, qué pueden hacer y en nombre de quién. Eso es un problema de identidad y autorización — exactamente el terreno de Keycloak. Que el proyecto se esté preparando para esto significa que Keycloak quiere ser la capa de identidad también para las aplicaciones de IA, no solo para las tradicionales.
Soporte experimental (--features=cimd) para MCP versión 2025-11-25 o posterior.
Guía: Keycloak como servidor de autorización para MCP · Issue de soporte CIMD (#45106).
6. Exportación de métricas con OpenTelemetry — observabilidad unificada
(Experimental · disponible desde la versión 26.5)
Qué es: OpenTelemetry es el estándar para recoger métricas, logs y trazas de un sistema. Keycloak ya permite exportar logs y, de forma experimental, también métricas a cualquier backend compatible.
Por qué importa: cuando algo va mal en producción —lentitud, errores intermitentes, picos de carga— necesitas datos para encontrar la causa. Que Keycloak hable el mismo idioma de observabilidad que el resto de tu infraestructura significa que puedes verlo todo en un único panel, en lugar de tener Keycloak como una caja negra aparte.
Introducido en la versión 26.5. Anuncio de la release 26.5.
Qué hacer con esta información
No se trata de activar estas funcionalidades mañana. La mayoría no están listas para producción y algunas cambiarán antes de estabilizarse.
El valor está en otro sitio: saber qué viene permite tomar mejores decisiones hoy. Si estás diseñando tu arquitectura de identidad, conocer que SCIM, AuthZEN o la identidad descentralizada están en camino te ayuda a no construir algo que tengas que rehacer en dos años.
Y si una de estas funcionalidades resuelve un problema concreto que tienes ahora, puede merecer la pena explorarla en un entorno de pruebas — con criterio y entendiendo sus límites.
¿Estás valorando cómo encajará alguna de estas funcionalidades en tu arquitectura de identidad? Podemos ayudarte a separar lo que ya es sólido de lo que conviene esperar. Cuéntanos tu caso.
En IDPTrust nos especializamos exclusivamente en Keycloak: despliegue, migraciones y operación en producción. Trabajamos en remoto con equipos en Europa, EE. UU. y Latinoamérica que necesitan un sistema de identidad fiable y bajo su control.