Keycloak en una plataforma de IA: dónde encaja, qué resuelve y los dos estándares que MCP exige y no implementa

Sat, 12 Sep 2026 07:30:00 +0200

Este artículo abre el bloque de identidad del track operativo. El anterior trató el lado del gateway: el JWT que no valida audiencia, el usuario que no llega a la traza. Este trata la pieza que hay al otro lado. Verificado contra Keycloak 26.7.3, la revisión 2026-07-28 de la especificación de MCP y el texto del Real Decreto 311/2022 en el BOE.

TL;DR

Keycloak 26.7.3 se publicó el 31 de agosto de 2026 y sigue en incubación en la CNCF, donde entró en abril de 2023. La cadencia es de cuatro versiones menores al año y el soporte cubre en la práctica una sola rama: los veinte fallos de seguridad corregidos en la 26.7.3 no se trasladaron a las ramas 26.4, 26.5 ni 26.6 en el momento de publicarse.

La distribución sobre Quarkus separa configuración de compilación y de ejecución. Lo que se fija en la fase de compilación queda congelado en la imagen, y cambiarlo al arrancar obliga a reconstruir. En contenedores, el patrón es compilar en la imagen y arrancar con la bandera de optimizado.

El almacenamiento es relacional y solo relacional. El motor alternativo que estuvo en desarrollo se retiró en la versión 25.0. Desde la 26.0 las sesiones se persisten en base de datos por defecto, lo que cambia el perfil de carga: el coste dominante en los bancos de pruebas oficiales es la CPU de la base de datos.

Organizaciones resuelve el multi-inquilino dentro de un realm, con soporte pleno desde la 26.0. Agrupa miembros, asocia dominios de correo y vincula proveedores de identidad por organización. Es la alternativa a replicar realms por cliente.

El cuello de botella medido es el hash de contraseña. Desde la 25.0 el algoritmo por defecto fuera de entornos FIPS es Argon2, con unos 7 MB de memoria por operación. La guía oficial de dimensionado da un vCPU por cada 15 inicios de sesión con contraseña por segundo, frente a 120 por segundo para credenciales de cliente y para refrescos.

Keycloak no implementa dos estándares que la especificación de MCP marca como obligatorios. Los metadatos de recurso protegido corresponden al servidor MCP, no al servidor de autorización, así que ahí no hay nada que reprochar. Los indicadores de recurso sí le corresponden y no están soportados. La propia documentación de Keycloak declara conformidad parcial con las tres últimas revisiones de MCP por ese motivo. El sustituto práctico son los ámbitos y un mapeador de audiencia.

Hay un fallo crítico reciente que conviene mirar hoy mismo. CVE-2026-18963, con puntuación 9,1, permitía restablecer la contraseña de cualquier usuario sin autenticarse, administradores incluidos. Corregido en 26.7.2, publicada el 19 de agosto de 2026.

Estás aquí: la capa transversal

La identidad no es una etapa del pipeline, es una capa que las cruza todas. Aparece en el hardening del stack como una de las siete capas de defensa, en la cadena de confianza del modelo como identidad de carga, en el gateway como validación de token, y en el artículo sobre autenticar servidores MCP como servidor de autorización.

Lo que faltaba era el artículo de la pieza en sí, y sobre todo la decisión de dónde ponerla y qué esperar de ella.

La analogía: el registro civil y los permisos de obra

Un ayuntamiento pequeño tiene un padrón, que dice quién vive allí, y tiene licencias, que dicen quién puede hacer qué. Son dos cosas distintas y conviene no confundirlas, porque el padrón vale para toda la ciudad mientras que una licencia vale para una obra concreta en una calle concreta.

Keycloak es el padrón. Sabe quién es cada persona, la identifica de forma fiable, sabe a qué colectivos pertenece y emite un documento acreditativo que caduca. Lo que no hace es decidir si esta persona puede modificar este fichero concreto: eso es la licencia, y vive en cada servicio.

La confusión entre las dos cosas produce el error de diseño más caro en plataformas de este tipo, que consiste en meter en el token todo lo que hará falta decidir después. El documento del padrón crece, se reparte por todas partes, y cuando cambia un permiso hay que esperar a que caduque el documento de todo el mundo.

Hay un tercer elemento que la analogía recoge bien. Un documento acreditativo emitido para presentar en Hacienda no debería servir para entrar en el depósito municipal. Eso es la audiencia del token, y es el asunto central de la segunda mitad del artículo.

Parte 1. Qué es Keycloak hoy

Estado del proyecto

Dato	Valor
Última versión estable	26.7.3, publicada el 31 de agosto de 2026
Anteriores	26.7.2 (19 de agosto), 26.7.0 (9 de julio), 26.6.0 (8 de abril)
Cadencia	cuatro versiones menores al año
CNCF	incubación desde el 10 de abril de 2023, sin graduar
Soporte	la rama actual; las anteriores no reciben correcciones de forma fiable

Ese último punto merece subrayarse porque condiciona la política de actualización. El análisis de la 26.7.3 muestra que sus veinte correcciones de seguridad no se trasladaron a las ramas anteriores al publicarse. Operar Keycloak significa ir al día de la rama vigente, no quedarse en una versión “estable” durante un año.

Desde la 26.0 hay garantía de compatibilidad hacia atrás en versiones menores para las funciones marcadas como plenamente soportadas, y los cambios que rompen son opcionales.

La arquitectura interna en cinco piezas

Dos modos de arranque. El de desarrollo habilita HTTP, no resuelve el nombre de host de forma estricta y desactiva la caché de temas. El de producción exige nombre de host y TLS, o no arranca. Confundirlos en producción es el primer antipatrón de la lista final.

La fase de compilación. El comando de construcción materializa las optimizaciones en la imagen. Las opciones de compilación, como el motor de base de datos, las funciones habilitadas o las métricas, quedan congeladas. Las de ejecución, como la contraseña de la base de datos o el nombre de host, se aplican al arrancar. Cambiar una opción de compilación al arrancar fuerza una reconstrucción con el coste de latencia correspondiente. El patrón correcto en contenedores es construir en la imagen y arrancar con la bandera de optimizado.

Extensiones por SPI. Autenticadores, mapeadores de protocolo, almacenamiento de usuarios, escuchas de eventos, algoritmos de hash y bóvedas de secretos. Se empaquetan como JAR y se resuelven en la fase de compilación.

Caché Infinispan. Embebida por defecto, con descubrimiento por base de datos como mecanismo recomendado. Las alternativas de descubrimiento por DNS de Kubernetes, TCP y UDP están obsoletas. Hay cachés locales, con capacidades por defecto de 10.000 entradas en varias de ellas, y cachés replicadas para sesiones, sesiones de cliente, sesiones sin conexión, sesiones de autenticación, fallos de inicio de sesión y tokens de acción. El modo remoto, con un Infinispan externo, hace falta para el despliegue multi-sitio de primera generación.

Almacenamiento relacional. JPA sobre base de datos. El motor alternativo se eliminó con la versión 25.0. Las bases soportadas hoy incluyen PostgreSQL de la 14 a la 18, MariaDB y MySQL en sus versiones de soporte extendido, SQL Server 2019 y 2022, Oracle 19c y 23.x, y las variantes gestionadas de Aurora PostgreSQL y Azure SQL.

El modelo conceptual mínimo

Antes de tocar nada hay que tener claros ocho conceptos, y el orden en que se relacionan:

Realm: la frontera de aislamiento. Usuarios propios, claves de firma propias, políticas propias. Dos realms no comparten nada.
Cliente: una aplicación que pide tokens. Público si no puede guardar un secreto, como una aplicación de navegador; confidencial si sí puede, como un servicio; y de solo portador si únicamente valida tokens sin pedirlos.
Ámbito de cliente: un paquete reutilizable de ámbitos y mapeadores, que se asigna a clientes como predeterminado o como opcional. Es la unidad con la que se acota lo que lleva un token.
Mapeador de protocolo: lo que proyecta un atributo, un rol o una audiencia dentro del token. El mapeador de audiencia es el que resuelve el problema central de este artículo.
Rol, de realm o de cliente, y rol compuesto, que agrega otros.
Grupo, jerárquico, con roles y atributos heredados.
Proveedor de identidad: federación hacia otro OIDC o SAML externo. Federación de usuarios: LDAP, Active Directory y Kerberos, con sincronización y mapeo de atributos.
Flujo de autenticación: una secuencia de ejecuciones con requisitos de obligatorio, alternativo, condicional o desactivado, y subflujos. Es donde se monta un segundo factor o una comprobación propia.

Y una función que cambia arquitecturas: organizaciones, plenamente soportada desde la 26.0. Resuelve el multi-inquilino dentro de un mismo realm, agrupando miembros, asociando dominios de correo y vinculando proveedores de identidad por organización, de forma que el descubrimiento del proveedor se hace por el dominio del correo del usuario. La alternativa clásica, un realm por cliente, multiplica la administración y no comparte configuración.

Parte 2. Quién puede autenticarse contra él

Esta es la tabla que hay que tener antes de dibujar nada. La columna de la derecha es la que suele decidir.

Pieza	Protocolo	Coste
API de Kubernetes	OIDC nativo, o el fichero de configuración estructurada de autenticación	Libre
LiteLLM	OIDC y JWT, más SSO de la interfaz	JWT y SSO por encima de cinco usuarios: Enterprise
vLLM	solo clave estática	No hay OIDC
Langfuse	OIDC genérico y proveedor Keycloak	SSO libre; control de acceso por proyecto: Enterprise
Grafana	OAuth genérico sí en la edición abierta	Sincronización de equipos: Enterprise
Backstage	OIDC genérico y proveedor Keycloak mantenido por la comunidad	Libre
Open WebUI	OIDC, con gestión de roles por claim	Libre
LibreChat	OIDC genérico, con Keycloak documentado	Libre
Argo CD	OIDC nativo o Dex, con grupos hacia su fichero de RBAC	Libre
MinIO	OIDC con asunción de rol mediante identidad web	Ver la nota de abajo

Dos precisiones que cambian decisiones.

Kubernetes. El mecanismo moderno es la configuración estructurada de autenticación, que permite varios emisores JWT y validaciones y mapeos con expresiones CEL. La propuesta correspondiente, KEP-3331, pasó a alfa en la 1.29, a beta en la 1.30 y es estable desde la 1.34. Es la vía a usar hoy, y sustituye a las banderas sueltas del API server.

vLLM no tiene identidad. Lo único que hay es una clave estática por variable de entorno. Esto no es un defecto a corregir, es un hecho de arquitectura: el motor va detrás del gateway y su control de acceso es de red, no de identidad. Cualquier diseño que exponga vLLM directamente a usuarios está renunciando a la trazabilidad por persona.

Sobre MinIO conviene una advertencia de honestidad: la documentación pública redirige hoy a la edición comercial, así que el detalle de cómo mapea políticas desde un claim está verificado ahí y no en la edición abierta. Quien dependa de ese mecanismo debería confirmarlo contra su propia versión antes de diseñar sobre él.

Parte 3. Humanos y máquinas

Son dos problemas distintos y conviene resolverlos por separado.

Personas

Código de autorización con PKCE, con método S256. La especificación de MCP lo exige cuando el cliente sea técnicamente capaz, y va más allá: obliga a rechazar el flujo si los metadatos del servidor de autorización no publican los métodos de desafío soportados.

Cargas sin persona detrás

Aquí la opción obvia son las credenciales de cliente con una cuenta de servicio de Keycloak, autenticada con secreto o, mejor, con JWT firmado por clave privada.

Pero hay una opción menos conocida y mejor para cargas dentro del cluster: la autenticación federada de clientes, presentada en enero de 2026 con el lema de acabar con los secretos. Permite que un cliente se autentique con un token emitido por un proveedor externo, y uno de esos proveedores es Kubernetes. El anuncio situaba el soporte pleno de la variante de cuentas de servicio de Kubernetes y de OIDC en la versión 26.6; la variante SPIFFE, en cambio, dice expresamente que seguirá en vista previa hasta que se cierre el estándar de autenticación de cliente SPIFFE en el IETF.

Eso significa que un pod puede autenticarse contra Keycloak con el token que el kubelet ya le proyecta, sin ningún secreto adicional que rotar. Conviene confirmar el estado exacto y el nombre de la bandera contra las notas de la versión que se tenga desplegada, porque la función es reciente y ha cambiado de estado entre la 26.5 y la 26.6. Es preferible al intercambio de tokens, cuya versión estándar está soportada pero es solo interno hacia interno, mientras que la antigua, la que cubría externo hacia interno y la suplantación, está obsoleta y en vista previa.

Keycloak frente a SPIFFE

La pregunta aparece siempre y la respuesta es que resuelven cosas distintas con un solapamiento pequeño.

SPIRE atesta el nodo y el proceso, y emite documentos de identidad de vida corta sin ningún secreto previo. Keycloak no atesta cargas: confía en una credencial que alguien tuvo que colocar, salvo en el caso de la autenticación federada que se acaba de mencionar, donde quien atesta es Kubernetes. A cambio, Keycloak federa personas, emite tokens con datos de negocio y gobierna el consentimiento, cosas que SPIFFE no hace.

La regla práctica: SPIFFE para identidad entre servicios dentro del perímetro, Keycloak para todo lo que tenga una persona detrás o cruce el perímetro. El detalle de SPIFFE está en el cierre de la serie de la cadena de confianza.

Parte 4. MCP, y los dos estándares que faltan

Esta parte es la que más consecuencias tiene y la que peor documentada está fuera de las fuentes primarias.

Lo que exige la especificación

De la revisión 2026-07-28, con las palabras normativas tal como aparecen:

El servidor MCP debe implementar los metadatos de recurso protegido del RFC 9728, y el cliente debe usarlos para descubrir el servidor de autorización.
El cliente debe implementar los indicadores de recurso del RFC 8707, incluyendo el parámetro resource tanto en la petición de autorización como en la de token, y debe mandarlo con independencia de que el servidor de autorización lo soporte.
El servidor MCP debe validar que el token de acceso se emitió específicamente para él como audiencia, y no debe aceptar ni retransmitir ningún otro token.
Los servidores de autorización y los clientes deberían soportar documentos de metadatos de identificador de cliente. El registro dinámico del RFC 7591 pasa a ser opcional y queda declarado obsoleto, retenido por compatibilidad.

La revisión añade además el emisor en la respuesta de autorización, del RFC 9207, y un modelo sin estado con manejadores de estado donde se dice expresamente que poseer un manejador de estado no equivale a estar autenticado.

Lo que soporta Keycloak

De su propia guía de integración con MCP:

Estándar	Keycloak
OAuth 2.1 y metadatos de servidor de autorización	Soportado
RFC 9207, emisor en la respuesta	Soportado
RFC 7591, registro dinámico	Soportado
Documento de metadatos de identificador de cliente	Soportado, experimental, tras activar la función
RFC 8707, indicadores de recurso	No soportado
RFC 9728, metadatos de recurso protegido	Fuera de alcance, es del servidor MCP

La conformidad declarada por el propio proyecto es “parcialmente soportado, sin indicadores de recurso” para las tres últimas revisiones de MCP.

Dos conclusiones prácticas:

El documento de metadatos de recurso protegido lo publica el servidor MCP o un proxy delante de él, nunca Keycloak. Es correcto y no hay nada que arreglar, pero hay que acordarse de implementarlo, porque el cliente lo necesita para descubrir a dónde ir.
Sin indicadores de recurso, la audiencia se acota con ámbitos. El camino oficial es usar el parámetro scope en lugar de resource, y colgar de ese ámbito de cliente un mapeador de audiencia con la URL del servidor MCP como audiencia personalizada incluida.

Es un rodeo, funciona, y hay que documentarlo en el diseño porque cualquiera que venga detrás buscará el parámetro estándar y no lo encontrará.

Parte 5. El delegado confuso

Con lo anterior encima de la mesa, el error clásico se ve solo. Un token con audiencia genérica convierte cualquier servicio comprometido en una llave maestra: quien obtiene el token que un usuario presentó al panel puede presentarlo al gateway, y de ahí al servidor MCP.

La especificación de MCP es explícita en tres frases que conviene citar tal cual en cualquier documento de arquitectura:

Los servidores MCP no deben aceptar tokens que no se emitieran explícitamente para ellos.
Si el servidor MCP llama a APIs de más arriba, no debe reenviar el token que recibió del cliente.
Los proxies MCP que usen identificadores de cliente estáticos deben obtener consentimiento del usuario por cada cliente registrado dinámicamente antes de reenviar a servidores de autorización de terceros.

Traducido a la figura concreta que se viene tratando en este track: el gateway no debe reenviar el JWT del usuario a servidores MCP de terceros. Tiene que obtener un token distinto con la audiencia correcta, o actuar como cliente OAuth propio. Por defecto, como ya se documentó en el artículo del gateway MCP, el comportamiento es usar la credencial propia del servidor, que es el correcto; hay dos modos que reenvían el token del llamante y ambos tienen nombre en la especificación.

Parte 6. Dos horas de tarea contra cinco minutos de token

La especificación empuja hacia tokens de vida corta y rotación obligatoria del token de refresco en clientes públicos. Una tarea agéntica de dos horas excede con holgura la vida de un token de acceso y puede exceder también la inactividad de la sesión si nadie refresca.

Tres opciones reales, con su coste:

Tokens sin conexión. Sobreviven a la expiración de la sesión, y caducan por inactividad propia o por un máximo si se activa esa limitación. El riesgo es evidente: una credencial casi permanente, difícil de inventariar. Y la especificación de MCP añade que los servidores MCP no deberían incluir ese ámbito ni en la cabecera de autenticación ni en los ámbitos soportados de sus metadatos.

Refresco automático en el cliente. Es la respuesta correcta cuando hay cliente que la pueda implementar, con rotación del token de refresco y almacenamiento seguro. Para un agente sin persona detrás, es mejor renovar por credenciales de cliente.

Claves virtuales de larga vida en el gateway. Funciona, y es lo que la mayoría acaba haciendo. El precio hay que escribirlo en el análisis de riesgos: la identidad queda desacoplada del proveedor, de modo que dar de baja a alguien en Keycloak no invalida su clave, y la trazabilidad hacia la persona real depende de la disciplina con que se hayan creado las claves. Las palancas que compensan son la caducidad, la rotación automática y el alias obligatorio, tratadas en el artículo de las claves virtuales.

Una nota de honestidad sobre los valores por defecto. Los números que circulan (cinco minutos de token de acceso, treinta de inactividad de sesión, diez horas de máximo) no aparecen publicados en la guía de administración ni los localicé en el código. Trátense como observación de consola y confírmense en el realm propio antes de citarlos en un documento.

Parte 7. Dimensionar y operar

En Kubernetes

El operador expone tres recursos personalizados: el servidor, la importación de realm y el cliente OIDC. Las sondas y las métricas viven en el puerto de gestión 9000, con las rutas de salud y preparación, y las métricas en formato Prometheus siempre que se haya habilitado la opción correspondiente en la fase de compilación. Ese puerto no se expone públicamente.

Para alta disponibilidad hay tres figuras. Un solo cluster repartido entre zonas, sin infraestructura adicional. Multi-cluster de primera generación, con balanceador externo e Infinispan externo en cada sitio. Y multi-cluster de segunda generación, introducido en la 26.7.0 y todavía en vista previa, que conecta clusters sin Infinispan externo, usando la base replicada de forma síncrona como fuente de verdad, con menos caché y más carga de base de datos.

Las cifras oficiales de dimensionado

De la guía de conceptos de dimensionado de CPU y memoria, que sigue publicada:

1 vCPU por cada 15 inicios de sesión con contraseña por segundo, probado hasta 300 por segundo.
1 vCPU por cada 120 concesiones de credenciales de cliente por segundo, probado hasta 2.000.
1 vCPU por cada 120 peticiones de refresco de token por segundo, probado hasta 435.
Dejar un 150 % de margen de CPU para picos, arranque y conmutación.
1.250 MB de memoria por pod con datos de realm y 10.000 sesiones en caché. Keycloak asigna el 70 % del límite al heap y unos 300 MB fuera de él, así que el límite sale de restar esos 300 MB al uso esperado y dividir entre 0,7.

Los supuestos declarados de esas cifras incluyen Argon2 con cinco iteraciones, sesiones en base de datos y la caché por defecto de 10.000 entradas.

La diferencia entre 15 y 120 es toda la historia del rendimiento de Keycloak: el coste está en el hash de contraseña. Desde la 25.0, el algoritmo por defecto fuera de entornos FIPS es Argon2, con unos 7 MB de memoria por operación. Antes era PBKDF2, cuyas iteraciones se multiplicaron por diez en la versión 24. En modo FIPS se sigue usando PBKDF2.

De ahí sale una consecuencia de arquitectura para una plataforma de IA: las cargas de máquina, que van por credenciales de cliente, cuestan ocho veces menos que un inicio de sesión humano. Dimensionar por número de servicios es barato; dimensionar por picos de inicio de sesión por la mañana es lo caro.

El banco de pruebas

Del informe de rendimiento de la 26.4, publicado el 1 de octubre de 2025: hasta 2.000 inicios de sesión por segundo y 10.000 refrescos por segundo con tres pods, 74 vCPU en total y 8 GB por pod, sobre una base Aurora PostgreSQL, con escalado vertical casi lineal.

Dos hallazgos útiles de ese informe. Con 20 ms de tiempo de ida y vuelta entre sitios, el percentil 99 sube de 51 a 130 ms, y el proyecto desaconseja desplegar entre regiones distintas. Y subir la caché de 10.000 a 200.000 entradas bajó el pico de CPU de la base de datos del 77,77 % al 63,77 %, a cambio de pausas de recolección de basura algo mayores.

Seguridad

El asunto urgente, si el despliegue está por debajo de la 26.7.2:

CVE-2026-18963, puntuación 9,1, crítico. Un salto del token de acción por correo en el flujo de restablecimiento de credenciales permitía restablecer la contraseña de cualquier usuario sin autenticación previa, administradores incluidos. Corregido en 26.7.2, publicada el 19 de agosto de 2026. La mitigación temporal, si no se puede actualizar, es desactivar la recuperación de contraseña en todos los realms. No consta explotación conocida a finales de agosto.

En la 26.7.3 hay otros diecinueve, entre ellos la falta de verificación del nombre de host en el certificado TLS hacia LDAP con puntuación 8,8, dos saltos de restricción de inquilino en el intercambio de tokens con corredores de Microsoft y Google, y dos saltos de control de acceso en organizaciones.

El endurecimiento oficial se resume en cuatro decisiones:

Nombre de host estricto, que es el valor por defecto desde la segunda generación de esa configuración. El servidor no deduce la URL de las cabeceras, lo que evita envenenar los enlaces de los correos y las redirecciones.
Consola de administración en un nombre de host distinto, y restringida en red.
Cabeceras de proxy declaradas explícitamente, confiando solo en un proxy inverso controlado.
Puerto de gestión separado y no expuesto.

Parte 8. El mapeo al ENS

Los códigos y títulos siguientes están verificados contra el texto oficial del Real Decreto 311/2022 publicado en el BOE, Anexo II.

Código	Título literal	Qué aporta un IdP central
op.acc.1	Identificación	Un identificador singular por entidad, usuario o proceso que accede
op.acc.2	Requisitos de acceso	Los permisos se conceden por rol y grupo, no por credencial suelta
op.acc.3	Segregación de funciones y tareas	Lo soporta con roles, pero el control es organizativo
op.acc.4	Proceso de gestión de derechos de acceso	Mínimo privilegio y política específica de acceso remoto
op.acc.5	Mecanismo de autenticación (usuarios externos)	Flujos y factores configurables por flujo
op.acc.6	Mecanismo de autenticación (usuarios de la organización)	Refuerzos exigidos ya en nivel bajo
op.exp.8	Registro de la actividad	Aporta una parte de los eventos, no todos
op.exp.10	Protección de claves criptográficas	Gestión y rotación de las claves de firma del realm

Dos matices que un auditor va a buscar.

El primero, sobre op.acc.1: el texto exige que cada entidad que accede al sistema, sea usuario o proceso, tenga un identificador singular. Eso incluye a los agentes. Una clave virtual compartida entre varios agentes no cumple, y es exactamente lo que suele pasar cuando la autenticación por JWT queda fuera del presupuesto.

El segundo, sobre op.exp.8: el control exige registrar el identificador del usuario o entidad asociado al evento, la fecha y hora, sobre qué información se realiza, el tipo y el resultado. Keycloak aporta los eventos de autenticación. Los eventos de uso los aportan el gateway y los servidores MCP, y ahí vuelven a aparecer los dos huecos ya documentados: las altas y bajas de servidores MCP no generan registro de auditoría y el usuario de la traza lo pone el cliente.

La correspondencia entre control y producto de esta tabla es interpretación propia y debe validarla la entidad de certificación. Los códigos y títulos, no: esos son literales del BOE.

Parte 9. La configuración que hay que dejar escrita

Tres piezas concretas, para no quedarse en el nivel de los conceptos.

Arranque endurecido, como argumentos del contenedor:

kc.sh start --optimized \
--hostname=https://sso.ejemplo.es \
--hostname-admin=https://sso-admin.interna.ejemplo.es \
--proxy-headers=xforwarded \
--health-enabled=true \
--metrics-enabled=true \
--http-management-port=9000 \
--cache=ispn --cache-stack=jdbc-ping \
--db=postgres

Las opciones de métricas, salud, caché y base de datos son de compilación: van en la imagen, y pasarlas aquí obliga a reconstruir si no coinciden.

El ámbito de cliente con audiencia, que es el rodeo obligado por la falta de indicadores de recurso. Creado con la herramienta de administración:

# un ámbito por recurso protegido
kcadm.sh create client-scopes -r plataforma \
 -s name=mcp-inventario -s protocol=openid-connect \
 -s 'attributes."include.in.token.scope"=true'

# el mapeador que fija la audiencia del token
kcadm.sh create "client-scopes/<id>/protocol-mappers/models" -r plataforma \
 -s name=aud-mcp-inventario \
 -s protocol=openid-connect \
 -s protocolMapper=oidc-audience-mapper \
 -s 'config."included.custom.audience"=https://mcp.ejemplo.es/inventario' \
 -s 'config."access.token.claim"=true'

El cliente pide ese ámbito y recibe un token cuya audiencia es solo ese servidor MCP. El servidor MCP valida la audiencia y rechaza cualquier otro token, como exige la especificación.

Importación del realm por GitOps, con el recurso personalizado del operador, para que la configuración no viva solo en la consola:

apiVersion: k8s.keycloak.org/v2beta1
kind: KeycloakRealmImport
metadata:
 name: plataforma
 namespace: identidad
spec:
 keycloakCRName: sso
 realm:
 realm: plataforma
 enabled: true
 # sin esto, el correo de recuperación es superficie de ataque
 resetPasswordAllowed: false
 bruteForceProtected: true
 sslRequired: all

Parte 10. Lo que Keycloak no resuelve

Autorización de grano fino sobre recursos. La pregunta “puede esta persona ver esta traza concreta” es una relación entre objetos, no un rol. Ese problema lo resuelven los motores de tipo Zanzibar, con OpenFGA y sus tuplas de objeto, relación y usuario, o un lenguaje de políticas como Cedar. Keycloak da roles y ámbitos, y con ellos no se modela un grafo de relaciones.

Secretos de máquina. Credenciales de almacenamiento, claves de proveedores, contraseñas de base de datos. Eso es un gestor de secretos, tratado en el hardening del stack.

Identidad criptográfica de carga con atestación. Eso es SPIFFE y SPIRE. En Keycloak existe como proveedor de identidad en vista previa, que es otra cosa.

Autorización dentro del modelo. Qué herramienta MCP puede invocar un agente, y con qué argumentos. La especificación ofrece ámbitos, el error de ámbito insuficiente y la elevación por pasos, pero la decisión por herramienta y por argumento la toma el servidor MCP o un motor de políticas, no el proveedor de identidad.

Antipatrones

Reenviar el token del usuario desde el gateway a servidores MCP de terceros. Prohibido explícitamente por la especificación.
Identificador de cliente estático con registro dinámico y sin consentimiento por cliente, que es la receta exacta del delegado confuso.
Ámbitos generales, del tipo acceso total, y publicar el catálogo entero de ámbitos soportados en los metadatos.
Tratar un manejador de estado como autenticación, que la revisión nueva prohíbe expresamente.
Seguir el descubrimiento de OAuth hacia cualquier URL, lo que abre la puerta a peticiones hacia direcciones internas. Aplica también al servidor de autorización cuando descarga un documento de metadatos de cliente.
Cabeceras de confianza mal expuestas en los front de chat. La documentación de Open WebUI avisa de que una configuración incorrecta permite autenticarse como cualquier usuario.
Arrancar en modo de desarrollo en producción, con el nombre de host sin resolver de forma estricta.
Una sola clave estática compartida como único control entre el gateway y el motor.

Checklist de arranque

Comprobar la versión. Por debajo de 26.7.2 hay un fallo crítico de restablecimiento de contraseña.
Construir la imagen con la fase de compilación hecha y arrancar con la bandera de optimizado.
Nombre de host estricto, consola de administración en otro nombre, puerto de gestión separado y no expuesto.
Decidir entre organizaciones y un realm por inquilino antes de crear el segundo inquilino.
Un ámbito de cliente por recurso, con mapeador de audiencia, porque los indicadores de recurso no están soportados.
En el gateway, definir las dos variables de audiencia y emisor. Sin ellas no se valida nada de eso.
Para cargas dentro del cluster, mirar el proveedor de identidad de Kubernetes antes de repartir secretos de cliente.
Dimensionar por picos de inicio de sesión, no por número de servicios: la diferencia es de ocho veces.
Exportar los eventos de Keycloak al mismo sitio donde van los del gateway, porque el control de registro de actividad los necesita juntos.
Escribir en el diseño qué hace el sistema con una tarea de dos horas, antes de que alguien resuelva el problema con un token sin conexión.

Cierre

Keycloak es una pieza madura que resuelve bien un problema acotado: saber quién es quien llama, y decirlo de forma verificable en un documento que caduca. En una plataforma de inferencia soberana eso vale mucho, porque la alternativa es un inventario de claves estáticas repartido por diez servicios que ninguna auditoría puede recorrer.

Lo que no conviene es pedirle más. La autorización fina vive en cada servicio, la identidad de carga con atestación vive en SPIFFE, y la decisión de qué herramienta puede llamar un agente vive en el servidor MCP.

Y hay una brecha concreta que conviene tener anotada, porque no se cierra sola: la especificación de MCP marca como obligatorios dos estándares, y de los dos que le corresponderían a un servidor de autorización, los indicadores de recurso no están implementados. El rodeo con ámbitos y mapeador de audiencia funciona, pero es un rodeo, y quien venga detrás buscará el parámetro estándar. Dejarlo escrito en el diseño ahorra una tarde.

Ver también

El gateway no vive solo: cómo valida el gateway los tokens que emite esta pieza, y las dos variables que hay que definir.
Cuando el MCP crece: ponerle autenticación con Keycloak: el montaje concreto para servidores MCP.
El gateway MCP de LiteLLM: la segunda puerta de entrada, sus permisos y su falta de registro de auditoría.
Cadena de confianza del modelo (4 de 4): SPIFFE, SPIRE y la identidad de carga con atestación.
Hardening y secretos del stack LLM soberano: dónde encaja la identidad entre las siete capas.
Claves virtuales, presupuestos y límites: la alternativa cuando el JWT queda fuera del presupuesto.
Controles técnicos: ENS, ISO 42001 y EU AI Act.
Completar Keycloak para MCP: la continuación: el lado del recurso protegido que hay que construir, el intercambio de token y la extensión empresarial de autorización.

Fuentes

Keycloak 26.7.3, 31 de agosto de 2026, y descargas.
Configuración del servidor, caché, bases de datos y nombre de host.
Integración con Model Context Protocol, intercambio de tokens y autenticación federada de clientes, 27 de enero de 2026.
Dimensionado de CPU y memoria e introducción a alta disponibilidad.
Bancos de pruebas de rendimiento de Keycloak 26.4, 1 de octubre de 2025.
Especificación de MCP, revisión 2026-07-28, autorización y buenas prácticas de seguridad.
KEP-3331, configuración estructurada de autenticación.
Real Decreto 311/2022, Anexo II.
Registro de CVE-2026-18963 en la base de datos de Red Hat y notas de la versión 26.7.3 en GitHub.
CNCF, proyecto Keycloak.

Sso on lo0 — Blog Técnico