Este post no es un alegato por Keycloak. Es la comparativa que le haríamos a un CTO que tiene que tomar la decisión en los próximos 30 días.

El contexto que lo cambió todo

En 2021, Okta adquirió Auth0 por 6.500 millones de dólares. Lo que siguió fue previsible: reestructuración de planes, eliminación de tiers, y subidas de precio que cogieron por sorpresa a muchas empresas que habían construido su arquitectura de identidad sobre Auth0.

No es una crítica — es la lógica de cualquier adquisición a esa escala. Pero para un CTO que está evaluando su stack de identidad hoy, significa que la ecuación económica de Auth0 en 2019 no es la de 2026.

Eso es lo que está empujando a muchas empresas a reabrir esta conversación.

El modelo de coste real

Auth0 cobra por MAU (Monthly Active Users) — usuarios que se autentican al menos una vez al mes. Suena razonable hasta que calculas lo que ocurre cuando creces.

Los precios de Auth0 varían según el plan y cambian con frecuencia. Verifica en su web antes de comparar.

Con Keycloak, el coste es infraestructura (servidores, base de datos, monitorización) más el equipo que lo opera — interno o externo. A partir de cierto volumen, la diferencia es significativa.

Control vs. servicio gestionado

Esta es la tensión real, y no tiene una respuesta universal.

Auth0 te da:

• Tiempo hasta producción muy rápido — horas, no semanas
• Infraestructura gestionada, sin páginas de guardia por caídas de tu IDP
• Documentación excelente y una experiencia de desarrollador que pocas herramientas igualan
• Actualizaciones automáticas de seguridad

Keycloak te da:

• Control total sobre flujos de autenticación, estructura de tokens y políticas de acceso
• Extensibilidad real — puedes modificar casi cualquier comportamiento mediante SPIs y extensiones
• Sin límites por MAU ni sorpresas en la factura
• Capacidad de despliegue on-premise, en tu nube o en cualquier entorno regulado

La pregunta no es cuál es mejor en abstracto. Es si tu organización tiene —o puede conseguir— la capacidad operativa para sacarle partido a ese control.

Soberanía del dato: el factor que suelen ignorar

Con Auth0, los datos de identidad de tus usuarios —emails, metadatos, historiales de sesión— viven en los servidores de Okta. Para muchas empresas esto no es un problema. Para otras, sí.

Situaciones en las que importa:

• GDPR en España y la UE: necesitas saber exactamente dónde están los datos y poder acreditar las transferencias internacionales
• Sectores regulados (banca, salud, gobierno): los requisitos de residencia de datos pueden excluir directamente las soluciones SaaS de terceros
• Clientes enterprise: algunos contratos incluyen cláusulas que restringen dónde se procesan los datos de autenticación

Con Keycloak, los datos viven donde tú decides. Punto.

El riesgo que nadie mide: el vendor lock-in

Auth0 está construido sobre estándares abiertos — OIDC, OAuth 2.0, SAML. En teoría, migrar debería ser posible.

En la práctica, el lock-in viene de otro sitio:

• Reglas de negocio personalizadas codificadas en Actions (el sistema de scripting propietario de Auth0)
• Hooks y flujos de login construidos con su UI específica
• Metadatos de usuario en su estructura de datos
• Integraciones con su marketplace

No es imposible migrar, pero tiene un coste real en tiempo de ingeniería. Y ese coste aumenta cada año que sigues construyendo sobre la plataforma.

Con Keycloak, el estándar es el centro de todo. Si en algún momento quieres cambiar, el protocolo —OIDC, SAML— es tuyo y portable.

Cuándo Auth0 tiene sentido

Seamos claros: hay escenarios en los que Auth0 es la opción correcta.

• Startup en fase temprana que necesita autenticación en producción esta semana, sin equipo de infraestructura
• MVP o prueba de concepto donde la velocidad lo es todo y el coste no es el problema
• Producto SaaS B2C con una base de usuarios pequeña y estable
• Equipo sin experiencia en operaciones de infraestructura y sin presupuesto para un partner especializado

En estos casos, la simplicidad y la velocidad de Auth0 compensan el coste y la dependencia. No tiene sentido operar Keycloak si no tienes las condiciones para hacerlo bien.

Cuándo Keycloak gana

• Sector regulado — banca, salud, seguros, gobierno — donde la soberanía del dato no es negociable
• Arquitectura compleja que requiere flujos de autenticación personalizados, federación de identidades o integración con sistemas legacy
• Estrategia multi-tenant con requisitos de aislamiento por cliente
• Equipos técnicos con capacidad de operar infraestructura, o acceso a un partner especializado que lo haga por ellos

En estos escenarios, el control que da Keycloak no solo justifica el coste operativo — lo supera con creces.

La decisión

Si estás evaluando esto ahora, la pregunta más útil no es "¿cuál es mejor?" sino "¿qué nos va a costar más dentro de tres años: operar Keycloak o depender de Auth0?"

Esa respuesta depende de tu volumen de usuarios, tu sector, tu equipo y tu tolerancia a la dependencia de un proveedor externo.

Si quieres trabajar los números con tu contexto concreto, hablamos.

En IDPTrust somos especialistas en Keycloak. Si estás en medio de esta decisión, podemos ayudarte a evaluar las opciones sin sesgos.

Auth0 / Okta

✅ El tiempo hasta producción más rápido. La mejor experiencia de desarrollo y documentación del mercado.
✅ Servicio gestionado — sin infraestructura que operar ni mantener.
❌ El precio escala agresivamente con los MAUs. Doloroso a partir de 50k+ usuarios.
❌ Control limitado sobre los flujos de autenticación y la estructura de tokens.

Mejor opción para: startups y productos SaaS que necesitan IAM rápido y pueden asumir el coste.

→ Ver comparativa detallada Keycloak vs Auth0

Microsoft Entra ID

✅ Integración perfecta con el stack de Microsoft — M365, Teams, Azure, Dynamics.
✅ Prácticamente gratuito si ya pagas por M365 E3/E5.
❌ Fuera del ecosistema Microsoft, la complejidad de integración aumenta significativamente.
❌ Licencias vinculadas a los planes de Microsoft 365 — difícil de desacoplar si tu stack cambia.

Mejor opción para: organizaciones totalmente comprometidas con Microsoft, con necesidad limitada de federación de aplicaciones no Microsoft.

Authentik

✅ Interfaz moderna, más fácil de operar que Keycloak para casos de uso sencillos.
✅ Código abierto con desarrollo activo y una comunidad en crecimiento.
❌ Menos maduro para escenarios empresariales — soporte SAML limitado, menos puntos de extensión.
❌ Ecosistema más pequeño y menos conocimiento comunitario disponible.

Mejor opción para: equipos pequeños que quieren IAM autoalojado sin el peso operativo de Keycloak.

Ping Identity

✅ Diseñado específicamente para grandes entornos empresariales híbridos — la combinación on-prem + cloud más sólida del mercado.
✅ Motor de orquestación DaVinci para diseño de flujos de autenticación sin código.
✅ Herramientas de cumplimiento sólidas: GDPR, HIPAA, SOX, PCI DSS desde el primer momento.
❌ Precios premium — planes workforce desde $3–6/usuario/mes, CIAM desde $35k/año.
❌ Despliegues complejos: 2–4 meses para lo básico, 6–12 meses para implantaciones grandes.
❌ La configuración de atributos personalizados OIDC tiene puntos de fricción conocidos.

Mejor opción para: grandes empresas con entornos híbridos on-prem/cloud e infraestructuras complejas de Active Directory.

One Identity

✅ IGA sólido — aprovisionamiento automatizado, certificación de accesos, controles basados en roles.
✅ Excelente gestión de Active Directory mediante Active Roles — el producto más valorado de su suite.
✅ Amplia biblioteca de conectores predefinidos para SAP, Oracle, Exchange y más.
❌ Suite de productos separados en lugar de una plataforma unificada — la evaluación y las licencias se complican.
❌ La interfaz está obsoleta y tiene fama de ser lenta en entornos grandes.
❌ Esfuerzo de implementación elevado; el desarrollo backend todavía depende de VB.NET en partes.

Mejor opción para: grandes empresas con necesidades IGA complejas, un footprint AD significativo y tolerancia para la complejidad de implementación.

Keycloak

✅ La plataforma IAM open source más completa — OIDC, SAML, LDAP, autorización detallada, SPIs personalizados.
✅ Sin licencias por usuario. Tu infraestructura, tus datos, tus costes bajo control.
✅ Probado en entornos empresariales con millones de usuarios. Proyecto de incubación de la CNCF.
❌ La carga operativa es real — las actualizaciones, la alta disponibilidad y el ajuste de rendimiento requieren experiencia.
❌ La consola nativa tiene limitaciones: la gestión masiva de usuarios, los logs de auditoría persistentes y el acceso contextual necesitan extensiones.

Mejor opción para: organizaciones medianas y grandes que necesitan control total, federación compleja, u operan en entornos regulados donde la residencia de datos y el coste de licencias son determinantes.

El resumen honesto

¿Qué impulsa tu decisión de plataforma IAM?

En IDPTrust nos especializamos en Keycloak en producción. Si necesitas ayuda para elegir la plataforma IAM correcta o desplegar Keycloak a escala, contáctanos.

A continuación, lo que cambió y por qué importa para los equipos que ejecutan Keycloak en producción.

Cinco funcionalidades pasan de vista previa a soporte completo

JWT Authorization Grant (RFC 7523)

Intercambio de tokens externo a interno mediante afirmaciones JWT firmadas.

Un cliente puede presentar una afirmación JWT firmada externamente — emitida por una autoridad externa de confianza — y obtener un token de acceso OAuth 2.0 de Keycloak sin un secreto de cliente independiente. Esto es especialmente relevante para la autenticación entre servicios a través de dominios de confianza, donde compartir secretos es poco práctico o donde un emisor externo (otro IdP, un clúster de Kubernetes, un proveedor de nube) es la fuente natural de identidad.

Autenticación federada de clientes

Los clientes se autentican usando relaciones de confianza existentes — sin más secretos por cliente.

Los clientes ahora pueden autenticarse en Keycloak utilizando una relación de confianza existente con un emisor externo, incluyendo proveedores de identidad OIDC y Kubernetes Service Accounts. En entornos donde docenas de microservicios mantienen cada uno su propio secreto de cliente, esto elimina tanto la sobrecarga de gestión como el riesgo de rotación.

Nota: La autenticación OAuth SPIFFE de clientes permanece en vista previa ya que la especificación todavía está en borrador.

Workflows

Capacidades IGA — nativamente en Keycloak, definidas en YAML.

Los Workflows permiten a los administradores automatizar tareas administrativas del realm mediante pipelines definidas en YAML, activadas por eventos, condiciones o programaciones. Las operaciones admitidas incluyen gestión del ciclo de vida de usuarios y clientes — aprovisionamiento, desaprovisionamiento y transiciones de estado.

Esta es la funcionalidad más significativa de esta publicación para entornos regulados. Incorpora capacidades de Identity Governance and Administration (IGA) de forma nativa en Keycloak, reduciendo la necesidad de herramientas externas para automatizar procesos de identidad como los flujos de incorporación, cambio y baja de empleados.

Actualizaciones de parche sin tiempo de inactividad

Actualizaciones progresivas dentro del mismo flujo major.minor — habilitadas por defecto.

Las actualizaciones progresivas dentro del mismo flujo major.minor ahora son compatibles sin interrupción del servicio. Esto está habilitado por defecto. En Kubernetes con el Operador de Keycloak, establece la estrategia de actualización en Auto para beneficiarte automáticamente.

Importante: esto aplica solo a actualizaciones de versión de parche (p. ej. 26.5.5 → 26.5.7). Las actualizaciones de versión menor (26.5 → 26.6) siguen requiriendo una ventana de mantenimiento planificada.

Keycloak Test Framework

JUnit 6 — reemplaza Arquillian + JUnit 4.

El nuevo framework gestiona de forma transparente el ciclo de vida de Keycloak, la base de datos y los recursos inyectados. Relevante para equipos que construyen SPIs o extensiones personalizadas.

Otros cambios que vale la pena mencionar

• Soporte para Java 25 — Keycloak ahora se ejecuta en OpenJDK 25. La imagen de contenedor continúa usando OpenJDK 21 por compatibilidad FIPS.
• Prefijo de variable de entorno KCRAW_ — Los valores que contienen caracteres $ inyectados mediante secretos de Kubernetes eran silenciosamente alterados por la evaluación de expresiones de SmallRye. KCRAW_ preserva el valor exactamente como se proporcionó.
• Cambio de contraseña forzado por LDAP — Keycloak ahora respeta el control "must change password" del servidor LDAP. Anteriormente, los usuarios podían pasar sin que se les solicitara el cambio.
• Cierre HTTP elegante — Drenaje de conexiones durante el apagado antes de terminar, reduciendo respuestas de error durante reinicios progresivos.
• Servidor de autorización MCP (experimental) — Keycloak ahora puede actuar como servidor de autorización para el Model Context Protocol versión 2025-11-25+.
• Token Exchange V1 deprecado — Planifica tu migración a V2.

¿Deberías actualizar?

Sí, y sin urgencia — esta no es una publicación de seguridad. Planifica la actualización dentro de tu ventana de mantenimiento habitual.

Si ejecutas Keycloak en Kubernetes con el Operador, las actualizaciones de parche sin tiempo de inactividad están habilitadas por defecto, lo que simplifica futuras actualizaciones dentro del flujo 26.x.

Notas de publicación completas: keycloak.org/2026/04/keycloak-2660-released

En IDPTrust nos especializamos en Keycloak en producción. Si necesitas ayuda para evaluar esta publicación o planificar una actualización, contáctanos.

A continuación, un desglose de lo que se corrigió y la severidad de cada problema.

Críticos — parchea de inmediato

CVE-2026-4282 · CVSS 7.4 (Alto) — Escalada de privilegios mediante códigos de autorización falsificados

El componente SingleUseObjectProvider, un almacén global de clave-valor utilizado internamente por Keycloak, carece de aislamiento adecuado de tipo y espacio de nombres. Un atacante no autenticado puede explotar este fallo para falsificar códigos de autorización y utilizarlos para obtener tokens de acceso con privilegios de administrador — sin credenciales y sin interacción del usuario.

Esta es la vulnerabilidad más peligrosa de esta publicación. No requiere autenticación, no requiere interacción del usuario, y una explotación exitosa otorga al atacante control administrativo completo sobre tu instancia de Keycloak.

Qué revisar: Examina cualquier exposición de red externa de tus endpoints de Keycloak. Asegúrate de que tu instancia esté actualizada antes que cualquier otra cosa.

CVE-2026-3872 · CVSS 7.3 (Alto) — Omisión de validación de redirect URI mediante path traversal

Un fallo en la forma en que Keycloak valida redirect URIs con patrones comodín permite a un atacante que controla cualquier otra ruta en el mismo servidor web eludir la restricción de ruta permitida usando una secuencia ..;/ en el endpoint de autorización OIDC. Una explotación exitosa conduce al robo del token de acceso.

Qué revisar: Si tu instancia de Keycloak comparte hostname con otras aplicaciones, esto es especialmente relevante. Revisa tus configuraciones de redirect URI y asegúrate de que los patrones comodín sean lo más restrictivos posible.

Altos — revisa tu configuración

CVE-2026-4636 — Inyección de política UMA permite conceder permisos entre usuarios

Un usuario autenticado puede inyectar una referencia de recurso en una política UMA de forma que le concede acceso no autorizado a recursos de otros usuarios. Afecta a despliegues que usan UMA 2.0 para compartir recursos.

CVE-2026-3429 — Control de LoA incorrecto durante la eliminación de credenciales (Account API)

La Account REST API no aplica correctamente el Level of Assurance requerido cuando un usuario elimina una credencial. Esto puede explotarse para eliminar factores MFA y tomar el control de una cuenta sin cumplir los requisitos de autenticación que exige la política.

CVE-2026-4634 — DoS a nivel de aplicación mediante procesamiento de scopes

Keycloak no limita adecuadamente el procesamiento de parámetros de scope de OpenID Connect. Un atacante no autenticado puede enviar peticiones manipuladas que provoquen un procesamiento excesivo, degradando la disponibilidad de la instancia sin necesidad de credenciales.

Moderados

CVE-2025-14083 — Divulgación de información mediante la Admin REST API

Un usuario con únicamente el permiso create-client — considerado de bajo privilegio por diseño — puede acceder al endpoint /admin/realms/master/users/profile y leer datos internos del esquema de perfil de usuario, incluidos nombres de atributos, reglas de validación y mapeos de permisos.

CVE-2026-1002 — Manipulación de caché de ficheros estáticos de Vert.x

El manejador de ficheros estáticos del framework Vert.x subyacente puede tener su caché manipulada de forma que deniega el acceso legítimo a recursos estáticos. Corregido en esta publicación mediante la actualización de la dependencia Quarkus 3.27.3.

Cambios adicionales

• Quarkus actualizado a 3.27.3.
• Una corrección de bug: las llamadas sin cabecera Host ya no lanzan un error no capturado.

¿Deberías actualizar?

Sí, y pronto. Dos de estos CVEs no requieren autenticación para ser explotados. La superficie de ataque es cualquier instancia de Keycloak accesible a través de la red.

Si estás ejecutando una versión anterior a la 26.5.7 — o peor aún, todavía en una distribución basada en WildFly — esta publicación es un buen recordatorio de que mantenerse actualizado no es solo una buena práctica, es un requisito de seguridad.

Notas de publicación completas: keycloak.org/2026/04/keycloak-2657-released

En IDPTrust nos especializamos en Keycloak en producción. Si necesitas ayuda para evaluar el impacto de esta publicación en tu entorno o planificar una actualización, contáctanos.

Severidad: Moderada Paquete afectado: org.keycloak:keycloak-services (Maven) Versiones afectadas: > 26.2.0, < 26.2.6 (solo cuando FGAPv2 está habilitado) Versiones parcheadas: 26.2.6 y 26.3.0

¿Cuál es el problema?

Un fallo en la aplicación de permisos de administración permite a un usuario con privilegios manage-users auto-asignarse realm-admin cuando FGAPv2 está habilitado en Keycloak 26.2.x. Causa raíz: ausencia de comprobaciones de límites de privilegio durante el mapeo de roles a través de la Admin REST API. Impacto: un administrador limitado malintencionado podría escalar a administración completa del realm, incluyendo la configuración del realm y el acceso a datos de usuarios.

¿Quién está afectado?

• Despliegues en Keycloak 26.2.x con FGAPv2 habilitado.
• Los entornos en 26.2.6+ o 26.3.0 no están afectados.

Nuestro estado (IDPTrust)

• Todos los clientes gestionados han sido notificados.
• Las ventanas de parche están programadas en todos los entornos (desarrollo, staging, producción) para migrar a 26.2.6 o 26.3.0 según la compatibilidad.
• Estamos verificando el uso de FGAPv2 por realm y reforzando los límites de los roles de administración.

Acciones recomendadas

1. Actualiza a 26.2.6 o 26.3.0 lo antes posible.
2. Si no puedes actualizar de inmediato:
   • Deshabilita FGAPv2 temporalmente si tu despliegue lo permite.
   • Revisa las asignaciones de usuarios administradores; asegúrate de que ningún usuario con derechos limitados pueda editar sus propios mapeos de roles.
   • Restringe el acceso a la Admin REST API y audita su uso.
3. Audita los cambios recientes de roles de administración en busca de auto-asignaciones sospechosas.

Cómo comprobar tu despliegue

• Confirma tu versión de Keycloak: Consola de Administración → Server Info o etiqueta de imagen.
• Comprueba si FGAPv2 está habilitado en tu realm o en las notas de instalación.
• Revisa los Eventos de Administración para detectar cambios de mapeo de roles en usuarios administradores.

Cronología

• Aviso publicado: 29 de julio de 2025 (por rmartinc).
• Notificación y programación de parches por IDPTrust: 29-07-2025.

Para preguntas o ayuda para planificar la actualización, contacta con tu canal de soporte de IDPTrust.

Severidad: Moderada Paquete afectado: org.keycloak:keycloak-services (Maven) Versiones afectadas: <26.0.13, <26.2.6 Versiones parcheadas: 26.2.13, 26.2.6, 26.3.0

¿Cuál es el problema?

Existe un fallo en el flujo de primer login durante un login con IdP. Un atacante que ya tiene una cuenta registrada puede iniciar la vinculación de cuenta con la cuenta existente de una víctima. Durante el posterior paso de "revisar perfil", el atacante puede cambiar su dirección de email por el email de la víctima, lo que provoca el envío de un email de verificación a la víctima. Si la víctima hace clic en el enlace de verificación, el atacante puede obtener acceso a la cuenta de la víctima.

Aunque no es un ataque de cero interacción (la víctima debe hacer clic en el enlace de verificación), el email del atacante no aparece en el email de verificación, lo que convierte este escenario en una oportunidad de phishing.

Impacto

• Posible toma de control de cuenta si la víctima hace clic en el enlace de verificación enviado durante el flujo iniciado por el atacante.
• Afecta a despliegues que ejecutan las versiones vulnerables indicadas anteriormente.

Nuestro estado (IDPTrust)

• Todos los clientes gestionados han sido notificados.
• Las ventanas de parche están programadas en todos los entornos (desarrollo, staging, producción) para migrar a las versiones parcheadas indicadas en el aviso.
• Estamos auditando los flujos de vinculación de cuentas y verificación de email, y reforzando la monitorización alrededor de los Eventos de Administración y los flujos de login.

Acciones recomendadas

1. Actualiza a una versión parcheada lo antes posible (26.2.13, 26.2.6 o 26.3.0, según el aviso).
2. Hasta que actualices:
   • Considera deshabilitar o restringir la vinculación de cuentas donde sea factible.
   • Informa a los usuarios para que sean cautelosos ante solicitudes de verificación de email inesperadas.
   • Revisa la configuración del primer login con IdP y asegúrate de aplicar salvaguardas adicionales (p. ej., revisión manual) donde corresponda.
3. Audita los eventos recientes de login y vinculación de cuentas en busca de actividad sospechosa.

Cómo comprobar tu despliegue

• Confirma tu versión de Keycloak (Consola de Administración → Server Info, o tu etiqueta de imagen).
• Revisa los pasos de tu First Login Flow para logins con IdP, especialmente el comportamiento de "revisar perfil" y la verificación de email.
• Inspecciona los logs y los Eventos de Administración relacionados con intentos de vinculación de cuentas.

Cronología

• Aviso publicado: 29 de julio de 2025 (por rmartinc).
• Notificación y programación de parches por IDPTrust: 29-07-2025.

Referencias

• Aviso oficial: GHSA-xhpr-465j-7p9q – Phishing attack via email verification step in first login flow https://github.com/keycloak/keycloak/security/advisories/GHSA-xhpr-465j-7p9q