Identidad on lo0 — Blog Técnico

Completar Keycloak para MCP: el recurso protegido que ningún SDK te da hecho, y la extensión empresarial que se salta el flujo entero

Sat, 12 Sep 2026 09:00:00 +0200

Continuación de Keycloak en una plataforma de IA, que dejaba señalado el hueco: los indicadores de recurso no están soportados y los metadatos de recurso protegido corresponden al servidor MCP. Este artículo trata de cerrarlo. Verificado contra la revisión 2026-07-28 de la especificación, los SDK oficiales de Python y TypeScript, Keycloak 26.7.3 y LiteLLM 1.102.0.

TL;DR

La especificación reparte tres obligaciones y el servidor de autorización solo cubre una. El servidor MCP debe publicar sus metadatos de recurso protegido. El cliente debe mandar el indicador de recurso en las dos peticiones, y debe hacerlo aunque el servidor de autorización no lo soporte. El servidor MCP debe validar que el token se emitió para él. Keycloak no entiende el indicador y considera los metadatos ajenos, así que las tres acaban en la capa del recurso.

El SDK de Python monta los metadatos solo, pero degradados. En cuanto se configura la URL del servidor de recursos, la ruta aparece. Lo que publica esa ruta automática lleva un solo servidor de autorización, reutiliza como catálogo de ámbitos los que exige el middleware, y deja el nombre y la documentación a nulo. Para publicar un documento completo hay que montar la ruta a mano.

La validación de audiencia viene apagada en Python y no existe en TypeScript. En Python, si se configura la URL del recurso y no se activa el flag correspondiente, el SDK emite un aviso de obsolescencia y se comporta como si estuviera desactivado; el propio docstring promete que la versión 3 lo pondrá a cierto. En TypeScript la verificación del portador hace tres cosas, y ninguna es mirar la audiencia. Ninguno de los dos trae un verificador de firma con claves públicas.

El paso del token está prohibido por escrito, y el sustituto tiene nombre. La especificación dice que el servidor MCP no debe aceptar ni retransmitir tokens que no se emitieran para él, y que si llama a APIs de más arriba el token debe ser otro. El mecanismo es el intercambio de token, que Keycloak soporta en su versión estándar con una limitación que hay que conocer: la audiencia es un identificador de cliente, no una URL de recurso.

Hay una extensión oficial que cambia el dibujo entero, y está estable. La autorización gestionada por la empresa sustituye la redirección al servidor de autorización del MCP por un intercambio en el proveedor de identidad corporativo, que evalúa la política y emite una concesión basada en aserción de identidad. Es estable desde junio de 2026 y hay servidores en producción.

Keycloak la implementa a medias y en experimental. Solo sabe actuar como receptor, no como emisor, detrás de una bandera de función, y contra el borrador 01 cuando el grupo de trabajo va por el 04. La documentación oficial dice literalmente que no se use en producción.

LiteLLM ya la implementa del lado cliente y no lo documenta. En 1.102.0 hay un modo de autenticación hacia servidores MCP que ejecuta las dos etapas de esa concesión. No hay un solo fichero de documentación que lo mencione.

Estás aquí: el lado del recurso

El artículo anterior recorrió el proveedor de identidad. Este recorre lo que hay al otro lado del token, que es donde la especificación de MCP pone casi todas sus obligaciones normativas.

El orden de lectura natural es Cuando el MCP crece para el montaje básico, Keycloak en una plataforma de IA para la pieza de identidad, y este para la capa que falta. El gateway MCP visto desde dentro está en su propio artículo.

La analogía: el visado y el control de frontera

Un consulado emite visados. Un puesto fronterizo los comprueba. Son dos oficinas distintas, y el error clásico consiste en suponer que porque el visado sea auténtico sirve para entrar por cualquier puerta.

El visado lleva escrito para qué país vale. Esa es la audiencia del token, y aquí aparece el problema: el consulado con el que trabajamos no sabe escribir el destino que pide el viajero, porque no entiende ese campo del formulario. Sabe escribir un destino si se le pide con otro nombre, mediante un sello preacordado, que es el rodeo de los ámbitos y el mapeador de audiencia.

Y queda la otra mitad, que es la que casi nadie monta. El puesto fronterizo tiene que existir, tiene que anunciar dónde está y de qué consulados acepta visados, y tiene que leer el destino escrito en el visado antes de dejar pasar. Si el puesto fronterizo se limita a comprobar que el sello es auténtico y no mira el destino, cualquier visado válido del mismo consulado sirve para entrar. Eso es exactamente lo que hacen por defecto los dos SDK oficiales.

Parte 1. El reparto de obligaciones

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

Obligación	De quién	Estado con Keycloak
Publicar metadatos de recurso protegido (RFC 9728)	Servidor MCP, MUST	Fuera de su alcance, por diseño
Mandar el indicador de recurso (RFC 8707) en autorización y en token	Cliente, MUST, incluso si el servidor de autorización no lo soporta	No lo entiende
Validar que el token se emitió para uno mismo	Servidor MCP, MUST	Responsabilidad del recurso
No aceptar ni retransmitir otros tokens	Servidor MCP, MUST NOT	Responsabilidad del recurso
Validar el emisor de la respuesta de autorización (RFC 9207)	Cliente, MUST; servidor de autorización SHOULD emitirlo	Soportado
Consentimiento por cada cliente registrado dinámicamente	Proxy MCP con identificador estático, MUST	Configurable

Lo que más despista de ese reparto es la segunda línea. La especificación obliga al cliente a mandar el parámetro con independencia de que el servidor de autorización lo soporte. Con Keycloak, ese parámetro se pierde: la documentación oficial dice que no puede reconocerlo, y el comportamiento estándar ante un parámetro desconocido es ignorarlo. El cliente cumple, el token sale, y lo que no sale es la audiencia correcta. El fallo aparece más tarde y en otro sitio, que es el peor tipo de fallo.

Conviene saber dónde está ese trabajo. El asunto es la incidencia 14355 del proyecto, abierta, con hito en la 26.8.0. Hubo una implementación completa en la petición de cambios 35711, con mapeador propio y un punto de extensión para resolver recursos, que pasó a borrador en octubre de 2025 por falta total de pruebas y porque se decidió rehacerla por fases, empezando por un solo recurso por cliente. En marzo de 2026 se abrió una incidencia nueva para soporte experimental, también con hito en la 26.8.0 y sin petición de cambios asociada. En 26.7.x no hay bandera de función que lo active.

Novedades de la revisión que afectan al montaje

Cuatro cosas cambiaron respecto a la revisión anterior y conviene recogerlas:

RFC 9207. Sección nueva de validación de la respuesta de autorización. El cliente debe registrar el emisor del documento de metadatos validado, y la comparación es literal: no se permite normalizar mayúsculas, elidir el puerto por defecto, añadir o quitar la barra final ni recodificar caracteres antes de comparar.
Los tokens sin conexión salen del catálogo. Sección nueva sobre tokens de refresco: los servidores MCP no deberían incluir el ámbito correspondiente ni en la cabecera de reto ni en los ámbitos soportados de sus metadatos.
El registro dinámico queda obsoleto. Pasa de opcional a opcional y deprecado, retenido por compatibilidad con servidores de autorización que no soporten documentos de metadatos de identificador de cliente. Y se añade un requisito nuevo al registro: el tipo de aplicación es obligatorio, y un cliente no debe reutilizar credenciales de otro servidor de autorización, tiene que registrarse de nuevo.
La elevación por pasos se reescribe. Desaparece el menú de tres estrategias de servidor y se sustituye por dos reglas: el atributo de ámbito del reto describe lo que hace falta para el recurso pedido, sin obligación de incluir lo ya concedido, y la acumulación de ámbitos pasa a ser responsabilidad del cliente. Con un requisito nuevo para el servidor: debe tener en cuenta las jerarquías de ámbitos, donde uno amplio implica los estrechos.

Parte 2. Lo que los SDK dan, y lo que no

Aquí está la parte incómoda, y es la razón principal para escribir este artículo. Verificado leyendo el código del SDK de Python y del de TypeScript 2.0.0-alfa.

Los metadatos de recurso protegido

En Python existe el modelo completo y se monta solo. La clase de metadatos lleva los campos de la RFC: recurso, servidores de autorización con un mínimo de uno, URL del juego de claves, ámbitos soportados, métodos de portador con valor por defecto de cabecera, nombre, documentación, política, condiciones, y los campos de certificado de cliente y de DPoP. El manejador sirve el documento con una directiva de caché de una hora, y la URL se construye insertando la ruta conocida delante del camino del recurso, como pide la RFC.

En cuanto se configura la URL del servidor de recursos, la ruta aparece sin más trabajo. Pero lo que publica esa ruta automática está degradado en tres puntos: pasa un único servidor de autorización, toma como catálogo de ámbitos los que el middleware exige (que no son lo mismo que los que el recurso soporta), y no pasa ni el nombre ni la documentación, que salen a nulo. Para publicar un documento completo hay que llamar a la función de creación de rutas a mano.

En TypeScript existe y no se monta solo. La función que construye el documento emite solo cinco campos: recurso, servidores de autorización, ámbitos soportados, nombre y documentación. No emite los métodos de portador soportados, ni la URL del juego de claves, ni nada de DPoP. Y servirlo es explícito: o se llama a la función de respuesta desde el manejador propio, o se monta el enrutador de metadatos. No hay ningún punto del SDK que lo haga por su cuenta.

La validación de audiencia

Esta es la que hay que corregir el primer día.

En Python viene desactivada. El verificador de tokens es un protocolo de un solo método, es decir un hueco que rellena el implementador. El campo de recurso del token de acceso es el indicador que uno mismo pone. Y la comparación solo ocurre si se pide: hay una función que normaliza como URL e ignora la barra final, pero la URL del servidor de recursos le llega vacía salvo que se active el flag de validación.

El detalle que hay que leer dos veces está en la configuración: si la URL del recurso está puesta y el flag no, el SDK lanza un aviso de obsolescencia y se comporta como si el flag fuera falso. El docstring dice que la versión 3 pondrá el valor por defecto a cierto. Hasta entonces, un servidor Python configurado con autorización acepta tokens emitidos para otro recurso, salvo que el implementador active el flag o valide la audiencia dentro de su propio verificador.

En TypeScript no se valida en absoluto. La verificación del token portador hace exactamente tres cosas: separar el prefijo, comprobar los ámbitos requeridos y exigir que la expiración esté presente y no vencida. Una búsqueda de audiencia o de juego de claves sobre los paquetes de servidor y de middleware no devuelve ninguna validación. Todo queda en manos del verificador que se enchufe.

Ninguno de los dos trae un verificador de firma con claves públicas. En Python el único ejemplo es introspección contra el servidor de autorización, y su comprobación de audiencia está detrás de un flag que también viene a falso. En TypeScript la interfaz está vacía. Es decir: el componente que valida el token, que es el que sostiene el requisito normativo más importante de la especificación, es código propio en los dos casos.

El reto de autenticación

Python construye el reto con el error y su descripción, y añade la URL de los metadatos solo si está configurada. Devuelve 401 con token inválido y 403 con ámbito insuficiente, ambos por la misma función, así que los dos llevan la URL de metadatos. Lo que no emite nunca es el parámetro de ámbito, que la revisión 2026-07-28 pide que se incluya, y que es justo lo que el cliente necesita para saber qué pedir.

TypeScript sí emite el ámbito cuando hay ámbitos requeridos, además de la URL de metadatos, y mapea correctamente el token inválido a 401 y el ámbito insuficiente a 403.

Es decir, cada SDK tiene bien una mitad distinta. El de Python valida mejor y avisa peor; el de TypeScript avisa mejor y no valida.

Los ámbitos, que no son por herramienta

En los dos SDK los ámbitos son una lista estática a nivel de montaje del transporte, no por herramienta. No hay declaración de ámbito por herramienta ni ninguna ayuda de elevación por pasos del lado servidor. Emitir un 403 con el ámbito concreto que exige esa llamada, que es lo que la especificación describe, es código propio.

Ahí está el origen de casi toda la autorización fina que hay que construir, y por eso la Parte 6.

Qué revisión anuncia cada uno

Python ya está en 2026-07-28. La revisión aparece en las versiones conocidas y en la lista de versiones modernas, descritas como las que usan el sobre sin estado por petición. El método de descubrimiento del servidor está registrado con manejador por defecto, y las cabeceras de método y nombre se validan contra el cuerpo.

TypeScript la tiene, pero en una lista aparte. La constante de última versión de protocolo sigue en 2025-11-25, porque esa lista es solo la del saludo inicial. La era moderna vive en un módulo separado, con un comentario que explica la razón: mantenerlas deliberadamente separadas para que añadir una revisión ahí nunca filtre una cadena de versión moderna a un saludo de la era 2025.

Y conviene recordar el desajuste que ya salió en el artículo del gateway MCP: LiteLLM 1.102.0 sigue anunciando 2025-06-18.

Parte 3. Construir el recurso protegido

Con lo anterior, la lista de lo que hay que escribir queda corta y concreta.

1. Un verificador de token que valide la firma y la audiencia. Contra el juego de claves del realm, comprobando emisor, expiración y que la audiencia contiene la URL canónica del servidor MCP y solo cosas que le conciernen. Aquí entra el efecto secundario del rodeo de Keycloak: si un cliente pide dos ámbitos de dos recursos distintos, sale un token con dos audiencias, porque cada mapeador aporta la suya al array. No hay condición ni ejecutor de política de cliente en 26.7 que limite el número de audiencias por token. La defensa práctica es del recurso: rechazar tokens cuya audiencia incluya recursos ajenos, en lugar de limitarse a comprobar que la propia está presente.

2. El documento de metadatos completo, con todos los servidores de autorización que se acepten, el catálogo real de ámbitos que el recurso entiende, y el nombre y la documentación rellenos. En Python, montando la ruta a mano en lugar de dejar la automática. En TypeScript, montándola, a secas.

3. El reto de autenticación con el ámbito. En Python hay que añadirlo, porque el SDK no lo emite. Y hay que tener en cuenta las jerarquías de ámbitos, que es requisito nuevo de la revisión.

4. La decisión entre validación local e introspección. Validar la firma en local no cuesta red, pero la revocación no surte efecto hasta que el token expira: no hay listas de revocación para tokens firmados. La introspección cuesta una ida y vuelta por petición y solo la pueden invocar clientes confidenciales. La combinación razonable es vida de token corta y introspección en las operaciones que cambien estado.

5. El enlace del estado al usuario. La revisión nueva es explícita sobre esto, porque al desaparecer las sesiones de protocolo el estado se lleva en manejadores que viajan como argumento ordinario de herramienta. Los servidores deben verificar toda petición entrante y no deben tratar la posesión de un manejador como autenticación; y deberían atar el manejador al usuario del lado servidor, por ejemplo guardando el estado con una clave que combine el identificador de usuario derivado del token verificado con el manejador, y rechazar el manejador si lo presenta otro. Es un cambio de forma de trabajar respecto a las sesiones de antes.

Parte 4. El salto del gateway al servidor MCP

La figura real en una plataforma de inferencia no es cliente contra servidor MCP: es cliente contra gateway, y gateway contra servidor MCP. Ese segundo salto es donde se decide si la arquitectura es correcta.

La especificación no deja margen. El servidor MCP no debe aceptar ni retransmitir tokens que no se emitieran para él. Y si hace peticiones a APIs de más arriba, puede actuar como cliente OAuth de ellas, pero el token que use ahí es otro token, emitido por el servidor de autorización de arriba, y no debe reenviar el que recibió.

El mecanismo estándar para eso es el intercambio de token, y aquí hay que conocer tres detalles de Keycloak.

Primero, el modelo de permisos cambió. La versión antigua exigía permisos de administración finos y una autorización explícita de intercambio sobre el cliente destino. La versión estándar, soportada desde la 26.2, no los exige: basta con que el cliente solicitante sea confidencial y tenga activado el interruptor correspondiente. A cambio hay una condición que sorprende: el token del sujeto tiene que llevar al cliente solicitante en su audiencia, salvo que intercambie su propio token. Es decir, el gateway necesita aparecer en la audiencia del token de usuario, lo que se consigue con un mapeador de audiencia en un ámbito por defecto del gateway. Solo entonces puede reducir la audiencia a la del servidor MCP concreto.

Segundo, la audiencia es un identificador de cliente, no una URL de recurso. El parámetro filtra audiencias, es decir reduce, que es lo que se quiere. Pero toma el identificador de un cliente registrado en el realm. La consecuencia práctica es que el servidor MCP tiene que estar dado de alta como cliente, y su identificador debería ser su URL canónica, para que la audiencia resultante coincida con lo que el recurso valida. Es un truco de nomenclatura, y hay que documentarlo para quien venga detrás. La propia documentación lo reconoce: el intercambio de token todavía no soporta el parámetro de recurso.

Tercero, el tipo de token del sujeto está limitado. La versión estándar solo acepta tokens de acceso como sujeto.

Hay además una función experimental nueva en la 26.7 que añade un tipo de ámbito parametrizado para validar si el usuario solicitante está autorizado a actuar en nombre de otro. Interesante para delegación, pero experimental.

Lo que hace hoy el gateway

En LiteLLM 1.102.0 los modos de autenticación hacia servidores MCP son doce, con valor por defecto ninguno. Los que importan para esta discusión son cuatro.

oauth2_token_exchange implementa el intercambio estándar. Manda el tipo de concesión correcto, el token del sujeto y su tipo, y la audiencia, nunca el recurso. La omisión es deliberada según el propio código: fabricar un destino arriesga un error de destino inválido. Cachea el token resultante con una clave que combina el token del sujeto con toda la configuración, y con vida útil igual a la del token menos un minuto. Y bloquea, nunca degrada: sin token entrante devuelve 401, que el borde convierte en un reto con la URL de metadatos de recurso; un rechazo del proveedor de identidad devuelve 401; un error de configuración del gateway devuelve 500; un fallo de transporte, 503.

true_passthrough y oauth_delegate reenvían la cabecera de autorización del cliente tal cual. Eso es paso de token, con el nombre que le da la especificación, y su uso legítimo es estrecho: cuando el token que el cliente presenta ya se emitió para el servidor MCP de destino y el gateway es un mero transporte. Fuera de ese caso, incumple.

oauth2_id_jag es la sorpresa, y merece su propia parte.

Parte 5. La extensión empresarial, que cambia el dibujo

En junio de 2026 el proyecto MCP publicó una extensión de autorización que resuelve un problema distinto del que resuelve el flujo estándar, y que en una organización con proveedor de identidad propio es el problema de verdad.

El flujo normal es de usuario: cada empleado autoriza cada cliente contra cada servidor MCP. Funciona para aplicaciones de consumo y no funciona en una empresa, porque el alta de una persona exige autorizar decenas de servicios uno a uno y la baja exige revocarlos uno a uno.

La extensión io.modelcontextprotocol/enterprise-managed-authorization invierte eso. Está en el directorio de especificaciones estables del repositorio de extensiones, viene del SEP-990, y el flujo es este:

El cliente MCP autentica al usuario contra el proveedor de identidad corporativo por el flujo normal, y guarda la aserción de identidad, que puede ser un token de identidad de OpenID o una aserción SAML.
Cuando el servidor indica que hace falta autorización gestionada por la empresa, el cliente intercambia esa aserción en el proveedor corporativo por una concesión de autorización basada en aserción de identidad. El proveedor evalúa ahí la política de la organización: pertenencia a grupos, roles, acceso condicional.
El cliente presenta esa concesión al servidor de autorización del MCP y obtiene un token de acceso.
La frase que define la extensión, literal: no se redirige al usuario al endpoint de autorización del servidor de autorización del MCP.

El servidor de autorización del MCP valida la firma contra el juego de claves del proveedor corporativo, más audiencia, emisor y expiración, y usa el sujeto como identificador estable del usuario, con el correo como alternativa para enlazar cuentas anteriores.

Lo que eso compra es exactamente lo que pide un expediente de cumplimiento: política en un solo sitio, decisión auditable en el proveedor de identidad, y revocación centralizada que surte efecto en todos los clientes a la vez. El empleado que pierde el acceso deja de recibir concesiones, sin tocar ningún servidor.

El estándar de debajo es un borrador del grupo de trabajo de OAuth del IETF, con el nombre de concesión de autorización por aserción de identidad en JWT, revisión 04 de mayo de 2026, firmado por gente de Okta, Ping Identity y un autor independiente. Perfila el encadenamiento de identidad entre dominios de confianza combinando el intercambio de token con el perfil de JWT.

Y aquí viene el problema

Keycloak lo implementa solo a medias. Tiene página propia en la documentación, detrás de una bandera de función. Y tres limitaciones que hay que tener delante antes de diseñar nada:

Solo actúa como receptor. Acepta aserciones emitidas por un proveedor externo y emite tokens locales. El soporte nativo para actuar como emisor, dice la documentación, todavía no está completamente implementado. En el flujo de la extensión, el emisor es el proveedor corporativo: si ese proveedor es Keycloak, la pieza que falta es justo la que hace falta.
Está basado en el borrador 01 mientras el grupo de trabajo va por el 04.
La documentación oficial dice que no se use en producción.

La asimetría es llamativa y vale la pena señalarla: Keycloak no soporta un estándar con ocho años de publicado como son los indicadores de recurso, y sí soporta parcialmente un borrador de hace meses.

Lo que ya está en el gateway, sin documentar

En LiteLLM 1.102.0, el modo oauth2_id_jag ejecuta las dos etapas del flujo. En la primera pide al proveedor corporativo un intercambio de token con el tipo de token solicitado propio de esta concesión, mandando el token de identidad del usuario como sujeto y, opcionalmente, audiencia, recurso y ámbito. En la segunda presenta la aserción resultante al servidor de autorización del recurso con el tipo de concesión de portador de JWT. En las dos el gateway se autentica como cliente con JWT firmado por clave privada.

Dos avisos operativos que salen del código y que no están en ningún sitio más:

El sujeto sale del token de identidad del llamante, o del que se capturó en el inicio de sesión. Y solo el proveedor OIDC genérico captura aserciones: con Google, Microsoft o SAML no hay ninguna, y todos los usuarios fallan. El código emite un aviso al cargar la configuración.
Un servidor mal configurado rehúsa con 500 en lugar de caer a la credencial estática. Es la decisión correcta, y conviene saberla antes de que pase.

Y el aviso principal: no hay documentación. Ni un fichero en el repositorio que mencione este modo. Quien lo use está leyendo código, como este artículo.

Parte 6. La autorización por herramienta

Ninguna de las piezas anteriores responde a la pregunta que acaba haciendo el negocio: si esta persona puede llamar a esta herramienta con estos argumentos. El proveedor de identidad da roles y ámbitos, y con eso no se modela un grafo de relaciones, como ya se argumentó en el artículo anterior.

Lo que hay publicado hoy, con fuente:

OpenFGA es el único con guía de producto dedicada, actualizada el 9 de septiembre de 2026. El patrón es un tipo de herramienta con una relación de invocación, comprobada en cada llamada, y una consulta de listado para que el cliente solo vea las herramientas que puede invocar. Es patrón y lenguaje de modelado, no implementación de referencia.
Pomerium trae un criterio de política por herramienta, con coincidencia exacta, por prefijo, por sufijo y por lista.
Kong lo ofrece como producto, con listas de control por herramienta.
Traefik Hub llega hasta restricciones a nivel de parámetro, que es el grado más fino publicado.
Envoy tiene un filtro MCP que extrae atributos del protocolo para control de acceso fino, declarado en desarrollo activo y sin OAuth propio: el gancho es la autorización externa hacia un motor de políticas.

La opción de menor fricción en una plataforma que ya tiene malla de servicio es la autorización externa contra un motor de políticas. La de mayor expresividad, el modelo de relaciones.

Parte 7. Lo que sigue sin estándar

Dos huecos que no cubre la especificación y que hay que cerrar por fuera.

El cambio de definición de herramienta. Ni la revisión 2026-07-28 ni los SDK fijan hash de la descripción ni del esquema de entrada. La página de buenas prácticas cubre delegado confuso, paso de token, falsificación de petición del lado servidor en el descubrimiento, secuestro de manejadores de estado, confusión de servidores y validación del esquema de la URL de autorización, pero no hay ningún requisito de integridad ni de fijación. La herramienta que lo hace es el escáner de Invariant Labs, con licencia Apache 2.0, que fija hashes para detectar el cambio de definición tras la aprobación y trae además un modo proxy con guardarraíles. Ya salió en el artículo del gateway MCP y sigue siendo la única respuesta.

La guía pública que sí entra en esto es la de la NSA sobre consideraciones de diseño de seguridad en MCP, de mayo de 2026, hecha con el instituto de ingeniería de software de Carnegie Mellon. Dos observaciones suyas son directamente accionables: que la autorización en MCP es opcional y que la especificación no impone ningún requisito de gestión del ciclo de vida de los tokens, de modo que expiración y rotación quedan en manos de la organización; y la advertencia contra el descubrimiento dinámico de herramientas sin verificación de origen ni comprobaciones de autorización, que es el reconocimiento más directo del riesgo en una guía estatal.

Parte 8. Quién cubre qué

Con todo lo anterior, la tabla de decisión de la capa que se pone delante del servidor MCP:

Pieza	Publica metadatos de recurso	Valida audiencia	Intercambio de token	Autorización por herramienta
SDK Python, ruta automática	Sí, degradado	No por defecto	No	No
SDK TypeScript	No se monta solo	No	No	No
Traefik Hub (comercial)	Sí, automático	No documentado	No documentado	Sí, hasta parámetro
Kong, plugin de OAuth para MCP	No documentado	Sí	No documentado	Sí, listas por herramienta
Pomerium	Parcial	No documentado	No documentado	Sí, criterio por herramienta
agentgateway (Solo.io)	Sí	Sí, por política JWT	Sí, incluida la concesión de aserción	Sí, con expresiones
mcp-context-forge (IBM)	No en notas de versión	No documentado	Sí, desde 1.0.6	Sí, control por rol
Envoy, filtro MCP	No	No	No	Vía autorización externa
LiteLLM 1.102.0	Sí, y también de servidor de autorización	No sobre el JWT entrante	Sí, y concesión de aserción	Sí, permisos por clave y equipo

Dos avisos sobre esa tabla. El plugin de Kong exige versión mínima 3.12, está en vista previa técnica y necesita licencia de su edición de IA; además introduce un cambio incompatible en 3.13, que pasa a tratar todo el tráfico como MCP para cerrar un posible salto de autenticación. Y de oauth2-proxy no encontré documentación primaria ni a favor ni en contra del modo de recurso protegido: no afirmo que no lo tenga, afirmo que no está documentado donde pude mirar.

Configuración de referencia

Keycloak: el ámbito por recurso, opcional, con su audiencia. Que sea opcional y no por defecto es la pieza clave, porque es lo que hace que el cliente tenga que pedirlo explícitamente y funcione como sustituto del indicador de recurso:

kcadm.sh create client-scopes -r plataforma \
 -s name=mcp:inventario -s protocol=openid-connect \
 -s 'attributes."include.in.token.scope"=true'

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

Y el servidor MCP dado de alta como cliente con su URL canónica por identificador, para que el intercambio de token produzca la audiencia correcta:

kcadm.sh create clients -r plataforma \
 -s clientId=https://mcp.ejemplo.es/inventario \
 -s enabled=true -s publicClient=false -s consentRequired=true

El gateway, con intercambio de token en lugar de paso de token:

mcp_servers:
 inventario:
 url: "https://mcp.ejemplo.es/inventario"
 transport: "http"
 auth_type: "oauth2_token_exchange"
 client_id: "litellm-gateway"
 client_secret: os.environ/GW_SECRET
 token_exchange_endpoint: "https://sso.ejemplo.es/realms/plataforma/protocol/openid-connect/token"
 audience: "https://mcp.ejemplo.es/inventario"
 subject_token_type: "urn:ietf:params:oauth:token-type:access_token"
 token_exchange_profile: "rfc8693"

El verificador del recurso, que es lo que nadie da hecho. Lo esencial es la última comprobación, la que rechaza audiencias ajenas en lugar de conformarse con encontrar la propia:

RECURSO = "https://mcp.ejemplo.es/inventario"

async def verificar(token: str) -> AccessToken | None:
 claims = jwt.decode(
 token, await jwks(),
 algorithms=["RS256"],
 audience=RECURSO, # valida que estoy yo
 issuer=ISSUER,
 )
 aud = claims["aud"]
 aud = [aud] if isinstance(aud, str) else aud
 # y que no hay nadie más: el rodeo de los ámbitos permite
 # tokens con dos audiencias, y eso reabre el delegado confuso
 if set(aud) - {RECURSO, CLIENTE_GATEWAY}:
 return None
 return AccessToken(
 token=token,
 client_id=claims["azp"],
 scopes=claims.get("scope", "").split(),
 expires_at=claims["exp"],
 resource=RECURSO,
 )

Y al montar el servidor, el flag que no viene puesto:

auth = AuthSettings(
 issuer_url=ISSUER,
 resource_server_url=RECURSO,
 validate_token_resource=True, # sin esto solo hay un warning
 required_scopes=["mcp:inventario"],
)

Checklist

Activar la validación de audiencia en el SDK de Python, o escribirla en el verificador si es TypeScript. Sin eso, el requisito normativo central no se cumple.
Rechazar tokens con audiencias ajenas, no solo comprobar que la propia está presente.
Montar el documento de metadatos a mano, con todos los servidores de autorización y el catálogo real de ámbitos.
Añadir el parámetro de ámbito al reto, en Python, y contemplar jerarquías de ámbitos.
Dar de alta cada servidor MCP como cliente de Keycloak con su URL canónica por identificador, para que el intercambio de token produzca la audiencia correcta.
Sustituir cualquier modo de paso de token por intercambio de token, salvo el caso estrecho en que el token ya se emitió para el destino.
Comprobar que el gateway aparece en la audiencia del token de usuario, o el intercambio fallará.
Atar los manejadores de estado al usuario del lado servidor, y no tratarlos nunca como autenticación.
Decidir entre validación local e introspección sabiendo que la primera retrasa la revocación hasta la expiración, y acortar la vida del token en consecuencia.
Fijar hash de descripción y esquema de entrada por fuera, porque no lo cubre la especificación.
Poner un motor de políticas para la autorización por herramienta, y no intentar modelarla con roles.
Si se plantea la extensión empresarial, comprobar antes quién emite la concesión: Keycloak hoy solo sabe recibirla, en experimental y contra un borrador anterior.

Trampas y cosas que no son lo que parecen

El SDK de Python monta el documento de metadatos solo, y por eso parece resuelto. Lo que publica lleva un solo servidor de autorización y sin nombre ni documentación.

El aviso de obsolescencia de la validación de audiencia no activa nada. Avisa y sigue comportándose como desactivado.

El SDK de TypeScript no valida la audiencia en absoluto. No es configuración, es que no existe código para ello.

El reto de Python no lleva el ámbito, así que un cliente que reciba un 403 no sabe qué pedir.

El rodeo de los ámbitos permite dos audiencias en el mismo token. Cada mapeador aporta la suya, y no hay política de cliente que lo limite. La defensa está en el recurso.

La audiencia del intercambio de token es un identificador de cliente, no una URL. Si el servidor MCP no está dado de alta con su URL por identificador, la audiencia resultante no coincidirá con lo que el recurso valida.

El intercambio de token exige que el gateway esté en la audiencia del token de usuario. Es la condición que más tiempo hace perder la primera vez.

El registro dinámico de clientes está deprecado desde esta revisión, y el sustituto, los documentos de metadatos de identificador de cliente, es experimental en Keycloak y tiene un fallo abierto con documentos que traen campos desconocidos, lo que bloquea el inicio de sesión con clientes reales.

La concesión de aserción de identidad de LiteLLM depende del proveedor OIDC genérico. Con Google, Microsoft o SAML no se captura ninguna aserción y fallan todos los usuarios.

La elevación por pasos ya no es responsabilidad del servidor. La acumulación de ámbitos pasó al cliente en esta revisión.

La señal de elevación de autenticación va en un 401, no en un 403. El ámbito insuficiente es 403; pedir un nivel de autenticación mayor es otra cosa y otro código.

Cierre

El resumen de este artículo cabe en una frase: el proveedor de identidad es la mitad barata del problema, y la mitad cara es el recurso protegido, que ningún SDK da hecho y que en los dos oficiales viene con la validación de audiencia desactivada o ausente.

De ahí sale un orden de trabajo. Primero el verificador de tokens, con audiencia validada en los dos sentidos, porque sin él lo demás es decoración. Segundo, el documento de metadatos completo, montado a mano. Tercero, sustituir cualquier paso de token por intercambio, con el servidor MCP dado de alta con su URL por identificador. Cuarto, un motor de políticas para lo que los roles no modelan.

Y una decisión de calendario que conviene tomar con la información delante. La extensión de autorización gestionada por la empresa es el camino correcto para una organización con proveedor propio, está estable y tiene servidores en producción detrás. Lo que no está listo es Keycloak como emisor. Quien quiera ese flujo hoy tiene dos opciones honestas: delegar la mecánica en un gateway que la implemente, o esperar. Ponerlo en producción con una función que la documentación oficial marca como experimental y desaconseja expresamente no es una de ellas.

Ver también

Keycloak en una plataforma de IA: la pieza de identidad por dentro, y el hueco que este artículo cierra.
Cuando el MCP crece: ponerle autenticación con Keycloak: el montaje básico, anterior a esta revisión de la especificación.
El gateway MCP de LiteLLM: la segunda puerta de entrada, sus permisos, su coste y su falta de registro de auditoría.
El gateway no vive solo: la validación de audiencia que tampoco ocurre del lado del gateway.
Cadena de confianza del modelo (4 de 4): identidad de carga con atestación, el otro plano.
MCP por dentro y su observabilidad: el protocolo y sus primitivas.
El contratista con la llave maestra: aislar agentes de IA: el aislamiento de red que todo lo anterior presupone.

Fuentes

Especificación MCP, revisión 2026-07-28: autorización, registro de clientes y buenas prácticas de seguridad.
Extensión de autorización gestionada por la empresa y su especificación estable, del SEP-990. Anuncio de 18 de junio de 2026.
draft-ietf-oauth-identity-assertion-authz-grant, revisión 04 de 21 de mayo de 2026, grupo de trabajo OAuth del IETF.
Código de los SDK oficiales de MCP: python-sdk y typescript-sdk 2.0.0-alfa, clonados el 12 de septiembre de 2026.
Integración de Keycloak con Model Context Protocol, intercambio de tokens y concesión de autorización por aserción de identidad, consultados el 12 de septiembre de 2026.
Incidencias de Keycloak 14355, 47117 y 51039, y petición de cambios 35711.
Código de LiteLLM 1.102.0, commit 9071ca50 del 11 de septiembre de 2026.
NSA y SEI, Model Context Protocol: Security Design Considerations, mayo de 2026.
OpenFGA, autorización de servidores MCP, actualizado el 9 de septiembre de 2026.
mcp-scan de Invariant Labs, Apache 2.0.
Documentación de agentgateway, Traefik Hub, Kong y Pomerium, consultadas el 12 de septiembre de 2026.

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.

El gateway no vive solo: el JWT que no valida la audiencia, el usuario que nunca llega a la traza y las costuras que hay que escribir a mano

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

Octavo artículo del track operativo de la capa de control. Los siete anteriores tratan el gateway por dentro: el par con Langfuse, el día 2, las claves virtuales, humanos y agentes, el enrutado por prefijo, el gateway MCP y el dimensionado para agentes. Este trata lo que hay alrededor. Verificado contra LiteLLM 1.102.0 y Langfuse 4.35.0, ambos con commit del 11 de septiembre de 2026.

TL;DR

El gateway tiene cinco vecinos: una base de datos, una caché, un proveedor de identidad, un backend de trazas y un colector. Cada vecindad tiene su propia física, y estas son las siete cosas que decide.

El proxy arranca sin Postgres, pero entonces solo funciona la clave maestra. La variable DATABASE_URL es opcional (proxy_server.py:1163); sin ella, cualquier clave que no sea la maestra devuelve un 400 de conexión ausente (user_api_key_auth.py:1886). Con base de datos configurada pero caída, el comportamiento por defecto es devolver 503, salvo que se active general_settings.allow_requests_on_db_unavailable.

Redis nunca es obligatorio, y esa es justo la trampa. Hay un cortacircuitos con umbral de cinco fallos y recuperación de sesenta segundos (constants.py:456). Cuando se abre, el proxy no falla ninguna petición: degrada a memoria local. Lo que se pierde en silencio es que los límites de tasa dejen de ser globales y pasen a ser por pod.

Ningún backend de observabilidad puede tumbar una petición. Todos los callbacks se lanzan con asyncio.create_task y sus excepciones se capturan y registran (litellm_logging.py:3235). Si Langfuse no responde, los eventos se descartan al llenarse la cola. No hay latencia añadida, y tampoco hay registro fiable: la observabilidad del par es un dato estadístico, no un registro de auditoría.

La autenticación por JWT no valida ni la audiencia ni el emisor si no se definen dos variables. En _build_decode_kwargs (handle_jwt.py:1003) la audiencia sale de JWT_AUDIENCE y el emisor de JWT_ISSUER; si están vacías, el código fija verify_aud=False y verify_iss=False y emite un aviso una sola vez. Cualquier token válido firmado por ese proveedor, emitido para otro servicio, es aceptado.

El control de acceso basado en roles viene desactivado. enforce_rbac tiene valor por defecto False (_types.py:4848 y siguientes). Con ese valor, un token cuyo rol no se resuelve a nada no produce un 403: sigue el flujo. La autorización real, entonces, la aporta la pertenencia a equipo, si es que hay un claim de equipo configurado.

El identificador de usuario que llega a Langfuse no es el de Keycloak. El campo user_id de la traza se rellena con user_api_key_end_user_id (integrations/langfuse/langfuse.py:604), es decir con el campo user del cuerpo OpenAI, que lo pone el cliente. El sujeto del token y el dueño de la clave no viajan. Quien quiera trazabilidad de persona necesita configurar end_user_id_jwt_field o hacer que el cliente mande ese campo.

Langfuse no aprovisiona nada desde un claim. No existe variable que mapee un claim de OIDC a organización ni a proyecto. Lo único es asignación estática al alta con LANGFUSE_DEFAULT_ORG_ID y LANGFUSE_DEFAULT_PROJECT_ID, igual para todos. Además, el control de acceso por proyecto está detrás de la licencia Enterprise en la edición self-hosted, igual que los registros de auditoría y la retención por proyecto.

Estás aquí: entre las cuatro piezas

El par LiteLLM y Langfuse recorrió la costura entre el gateway y el backend de trazas: rutas de integración, coste que llega a cero, correlación y colas con descarte. Este artículo amplía el foco a las otras tres vecindades, con la identidad en el centro, porque es la que ordena todo lo demás y la que pide un auditor.

La pieza de identidad en sí, es decir Keycloak, la trata el artículo siguiente. Aquí se trata el lado del gateway.

La analogía: la obra con cinco gremios

En una obra pequeña, el problema no suele estar dentro del trabajo de cada gremio, sino en los encuentros: donde el fontanero deja el pasatubos y el albañil cierra el tabique, donde el electricista quiere pasar por el mismo hueco. Cada gremio hace bien su parte y el encuentro queda mal resuelto porque no es de nadie.

Una plataforma de inferencia tiene cinco gremios. El gateway sabe de tokens, el proveedor de identidad sabe de personas, el backend de trazas sabe de eventos, la base de datos sabe de gasto y la caché sabe de contadores. Cada uno tiene documentación buena. Los encuentros no tienen documentación de nadie, y ahí es donde se pierde la identidad del usuario entre el token y la traza.

Hay un detalle más de la analogía que sirve. En la obra, la parte que más problemas da no es la que se ve mal acabada, es la que se tapa. Aquí pasa igual: las cinco costuras de este artículo fallan en silencio.

Costura 1. Qué tumba y qué degrada

Conviene tener escrito qué pasa cuando cada vecino se cae, porque la intuición falla en casi todos los casos.

Vecino	¿Arranca sin él?	Si se cae
Postgres	Sí, solo con clave maestra	503 por defecto; degradado con `allow_requests_on_db_unavailable`
Redis	Sí	Cortacircuitos tras 5 fallos; límites pasan a ser por pod
Langfuse	Sí	Se descartan eventos al llenar la cola; sin impacto en latencia
Colector OTel	Sí	Igual que el anterior
Proveedor de identidad	Sí	Cae el acceso a la interfaz y el flujo JWT; las claves virtuales siguen

Postgres

Sin DATABASE_URL, _setup_prisma_client devuelve None sin error (proxy_server.py:10375). El proxy sirve /chat/completions con la clave maestra. Cualquier otra clave recibe un 400. Tampoco hay presupuesto global, y el propio arranque lo avisa: Redis no sustituye a la base de datos (proxy_server.py:9240).

Con base de datos configurada y caída, el manejador de excepciones relanza salvo que esté activo el flag de degradación (db/exception_handler.py:56). Hay además un DISABLE_PRISMA_HEALTH_CHECK_ON_STARTUP y un vigilante que reconecta. El detalle que importa para el diagnóstico: un fallo transitorio de base de datos devuelve 503, no 401. Si en un incidente se ven 401, el problema es de credenciales; si se ven 503, es de base de datos o de admisión.

Redis

El cortacircuitos está activado por defecto, con umbral de cinco fallos, recuperación de sesenta segundos y duración mínima de cinco (constants.py:456, lógica en caching/redis_cache.py:153). El socket tiene un timeout de 0,1 segundos (constants.py:453). Con el circuito abierto, DualCache sirve desde memoria sin propagar excepción (dual_cache.py:215).

La consecuencia hay que medirla, no suponerla: con cuatro workers y tres réplicas, un límite de cien peticiones por minuto se convierte en mil doscientas. Es un modo de fallo que no genera errores y que puede durar días sin que nadie lo note, hasta que llega la factura o el motor se satura.

La alerta correcta no es sobre Redis, es sobre litellm_service_latency etiquetada por servicio (integrations/prometheus_services.py:119), que expone la latencia de Redis y de la base de datos por separado.

Los callbacks

Todo lo que va detrás, es decir Langfuse y el colector, se lanza fuera del camino de respuesta y sus fallos se capturan. La integración clásica usa el SDK v2 con su propio hilo de fondo y un intervalo de vaciado de un segundo, ajustable con LANGFUSE_FLUSH_INTERVAL (langfuse.py:198). Hay un tope de cincuenta clientes Langfuse instanciados (constants.py:554), porque cada cliente es un hilo.

La integración por OTLP usa el procesador de lotes del SDK de OpenTelemetry (opentelemetry.py:3060) con sus valores por defecto. En los dos casos, saturación significa descarte, y el descarte no genera error hacia el cliente.

Costura 2. Identidad: las tres puertas y lo que valida cada una

Todo pasa por un constructor único de autenticación (user_api_key_auth.py:1245), con este orden:

Autenticación personalizada de la edición empresarial.
Rutas públicas.
OAuth2 opaco, si está activado, con comprobación de licencia.
JWT, si general_settings.enable_jwt_auth está activo y el token tiene tres partes.
Clave maestra, con comparación en tiempo constante.
Clave virtual, con hash SHA-256 y búsqueda en la tabla de verificación.

Un JWT sirve para /chat/completions, no solo para la administración: las rutas permitidas por defecto para un equipo incluyen openai_routes (_types.py:4886), que contiene el endpoint de chat. La administración, en cambio, solo la alcanza un token con rol de administrador.

Lo primero que hay que saber: es de pago

La rama JWT lleva una comprobación explícita de licencia, con el mensaje literal de que la autenticación por JWT es una función exclusivamente empresarial (user_api_key_auth.py:1416). El SSO de la interfaz de administración es gratuito hasta cinco usuarios facturables y exige licencia por encima (ui_sso.py:976).

Esto condiciona la arquitectura de cualquier despliegue soberano que no quiera pagar licencia: la integración con Keycloak queda para la interfaz de administración y para el aprovisionamiento, mientras que el tráfico de inferencia se autentica con claves virtuales. Las claves virtuales no son peores, pero son otra cosa, y hay que decirlo en el análisis de riesgos: son credenciales desacopladas del proveedor de identidad, de modo que dar de baja a una persona en Keycloak no invalida su clave.

Los campos de `litellm_jwtauth` que deciden la seguridad

De la clase LiteLLM_JWTAuth (_types.py:4848 y siguientes), estos son los que importan, con sus valores por defecto:

Campo	Defecto	Qué hace
`enforce_rbac`	`False`	Si es falso, un rol no resuelto no produce 403
`enforce_scope_based_access`	`False`	Sin esto, `scope_mappings` no se aplica
`enforce_team_based_model_access`	`False`	Acceso a modelos por equipo
`team_id_jwt_field`	`None`	Claim del que sale el equipo
`team_id_upsert`	`False`	Si es falso, un equipo que no existe da 404
`user_id_upsert`	`False`	Igual con el usuario
`public_key_ttl`	`600`	Caché de las claves públicas
`public_key_stale_ttl`	`3600`	Margen extra si el proveedor está caído
`admin_jwt_scope`	`litellm_proxy_admin`	Ámbito que otorga administración
`user_allowed_email_domain`	`None`	Restricción por dominio de correo

Los algoritmos aceptados son RS256/384/512, PS256/384/512, ES256/384/512 y EdDSA (handle_jwt.py:163). No hay ninguno simétrico, lo que elimina la clase de ataque por confusión de algoritmo. Es una buena decisión de diseño y conviene reconocerla.

La descarga de claves admite varias URL separadas por comas en JWT_PUBLIC_KEY_URL, resuelve el descubrimiento si la URL apunta a la configuración conocida de OpenID, reintenta tres veces con espera creciente y memoriza el fallo treinta segundos (handle_jwt.py:680, :751, :88). Si el proveedor está caído, sirve la copia caducada hasta la suma de los dos TTL, es decir hasta setenta minutos. Para disponibilidad está bien; para revocación no, y hay que escribirlo.

Un detalle de la rotación de claves: con más de una clave en el juego se exige coincidencia exacta del identificador de clave, pero con una sola clave y sin identificador se acepta sin comprobar (handle_jwt.py:913).

La validación que no ocurre

Esta es la parte que hay que corregir el primer día. En _build_decode_kwargs (handle_jwt.py:1003), la audiencia se toma de la variable de entorno JWT_AUDIENCE y el emisor de JWT_ISSUER. Si no están definidas, el código fija verify_aud=False y verify_iss=False, y emite un aviso una sola vez.

Lo que eso significa en un despliegue real con Keycloak: un token emitido para el cliente de Grafana, o para el de Backstage, firmado por el mismo realm, es aceptado por el gateway como credencial válida. La caducidad sí se valida siempre, con margen cero. La firma también. La audiencia no.

Hay una segunda vía, issuers, con configuración por emisor, que sí valida emisor y audiencia salvo que se desactive explícitamente (handle_jwt.py:1186). Es la que hay que usar cuando hay más de un proveedor.

La corrección mínima son dos líneas de entorno:

JWT_AUDIENCE=litellm-gateway
JWT_ISSUER=https://sso.ejemplo.es/realms/plataforma

Y del lado de Keycloak, un mapeador de audiencia en un client scope dedicado que inyecte esa audiencia. El detalle está en el artículo de Keycloak, porque el estándar que resolvería esto de forma limpia, los indicadores de recurso, no está soportado.

Del claim al permiso

El rol de administrador sale de que admin_jwt_scope aparezca en el claim scope, y devuelve resultado sin pasar por equipo (handle_jwt.py:309, :1373). El resto se resuelve por equipo.

Si el equipo del claim no existe en la base de datos, con team_id_upsert en falso se devuelve un 404 con el mensaje de que hay que crear el equipo (auth_checks.py:3035). Con el flag activo, se crea invocando el alta de equipo con una identidad sintética de administrador (auth_checks.py:2874). Esa es la única vía de aprovisionamiento automático que existe de Keycloak hacia el gateway, y funciona bien. Conviene saber que crea equipos sin presupuesto ni límites, de modo que hace falta un valor por defecto en la configuración.

La vulnerabilidad que conviene conocer

CVE-2026-35030, con puntuación 9,1 en CVSS 3.1 y 9,4 en CVSS 4.0, aviso GHSA-jjhc-v7c2-5hh6. Con la autenticación por JWT activa, la caché del endpoint de información de usuario de OIDC usaba los veinte primeros caracteres del token como clave, de modo que dos tokens con el mismo prefijo se confundían. Corregida en 1.83.0.

En 1.102.0 el código usa el hash SHA-256 completo (handle_jwt.py:962). Una búsqueda de patrones parecidos en el árbol no encuentra ninguna caché de autenticación indexada por prefijo de token: los recortes que quedan son enmascarados para el registro. Y merece recordarse lo ya publicado sobre el gateway MCP: por debajo de 1.83.14 hay ejecución remota o inyección SQL sin autenticar.

Costura 3. La identidad no llega a la traza

Aquí está el fallo de diseño más caro de la figura, porque se descubre en la primera auditoría.

El campo user_id de una traza de Langfuse se rellena con user_api_key_end_user_id (integrations/langfuse/langfuse.py:604 y :724), que proviene del campo user del cuerpo de la petición OpenAI o de end_user_id_jwt_field (litellm_pre_call_utils.py:1584). No es el sujeto del token ni el propietario de la clave virtual.

Las consecuencias en cadena:

Si el cliente no manda user, la traza no tiene usuario.
Si el cliente manda user, la traza tiene el valor que el cliente quiera poner, sin verificar.
Un agente que llama con una clave de servicio deja trazas sin persona detrás.

Hay tres formas de arreglarlo, en orden de robustez:

Configurar end_user_id_jwt_field para que el usuario final salga de un claim del token y no del cuerpo. Es la única opción en la que el valor no lo controla el cliente, y exige autenticación por JWT, es decir licencia.
Forzar el metadato trace_user_id, que sobrescribe el campo (langfuse.py:726; en la vía OTLP, langfuse_otel.py:96). Se puede fijar por equipo.
Obligar por contrato a que el cliente mande user y validar en un guardrail. Funciona, pero es una declaración del cliente, no una prueba.

Hacia el motor pasa algo parecido. La identidad del llamante no viaja a vLLM salvo que se active litellm.add_user_information_to_llm_headers, cuyo valor por defecto es None (litellm/__init__.py:223). Con ella se inyectan cabeceras x-litellm-* con identificador de usuario, de equipo y hash de clave (litellm_pre_call_utils.py:1356). El reenvío de cabeceras del cliente exige general_settings.forward_client_headers_to_llm_api, y la cabecera authorization se filtra siempre, lo cual es correcto.

Hacia los servidores MCP, por defecto se usa la credencial propia del servidor, no el token del usuario. Solo dos modos reenvían el token del llamante, y hacerlo tiene un nombre en la especificación de MCP: paso de token, que está explícitamente prohibido. Vuelve a salir en el artículo de Keycloak.

Costura 4. Langfuse como vecino

Lo que se puede automatizar y lo que no

La lista exacta de variables para SSO en Langfuse 4.x, tomada de web/src/env.mjs:

Con proveedor Keycloak: AUTH_KEYCLOAK_CLIENT_ID, AUTH_KEYCLOAK_CLIENT_SECRET, AUTH_KEYCLOAK_ISSUER, AUTH_KEYCLOAK_ALLOW_ACCOUNT_LINKING, AUTH_KEYCLOAK_CLIENT_AUTH_METHOD, AUTH_KEYCLOAK_CHECKS, AUTH_KEYCLOAK_ID_TOKEN_SIGNED_RESPONSE_ALG, AUTH_KEYCLOAK_SCOPE, AUTH_KEYCLOAK_ID_TOKEN, AUTH_KEYCLOAK_NAME.

Con OIDC genérico: el mismo juego con prefijo AUTH_CUSTOM_, más AUTH_CUSTOM_FETCH_USERINFO y el mapeo de claims con LANGFUSE_CUSTOM_SSO_SUB_CLAIM, LANGFUSE_CUSTOM_SSO_EMAIL_CLAIM, LANGFUSE_CUSTOM_SSO_NAME_CLAIM y LANGFUSE_CUSTOM_SSO_IMAGE_CLAIM.

Globales: AUTH_DISABLE_USERNAME_PASSWORD, AUTH_DISABLE_SIGNUP, AUTH_DOMAINS_WITH_SSO_ENFORCEMENT, AUTH_SESSION_MAX_AGE.

Y ahora lo que no hay. No existe ninguna variable que mapee un claim a organización o proyecto. Lo único es asignación estática al alta con LANGFUSE_DEFAULT_ORG_ID, LANGFUSE_DEFAULT_ORG_ROLE con valor por defecto VIEWER, LANGFUSE_DEFAULT_PROJECT_ID y LANGFUSE_DEFAULT_PROJECT_ROLE (features/auth/lib/createProjectMembershipsOnSignup.ts:61). La propia documentación lo confirma: el SSO empresarial no aprovisiona roles automáticamente en el alta.

Además, en la tabla de permisos por edición (features/entitlements/constants/entitlements.ts:139), las ediciones abierta y profesional self-hosted no incluyen el control de acceso por proyecto ni la API de administración. Son de la edición empresarial, igual que los registros de auditoría y la retención por proyecto. En la edición abierta, todo usuario hereda el rol de su organización.

El arranque declarativo, que sí existe

Para on-premise sin licencia, la vía practicable es el bootstrap por variables (web/src/initialize.ts), que es idempotente: LANGFUSE_INIT_ORG_ID (obligatorio, si falta se ignora el resto con un aviso), LANGFUSE_INIT_ORG_NAME, LANGFUSE_INIT_PROJECT_ID, LANGFUSE_INIT_PROJECT_NAME, LANGFUSE_INIT_PROJECT_RETENTION, LANGFUSE_INIT_PROJECT_PUBLIC_KEY, LANGFUSE_INIT_PROJECT_SECRET_KEY, LANGFUSE_INIT_USER_EMAIL, LANGFUSE_INIT_USER_NAME, LANGFUSE_INIT_USER_PASSWORD.

Con eso, un proyecto por inquilino se crea desde GitOps con un contenedor de inicialización por inquilino y las claves en secretos de Kubernetes.

Credenciales de Langfuse por equipo

Esta parte sí está bien resuelta del lado del gateway y poca gente la usa. TeamCallbackMetadata.callback_vars (_types.py:2152) admite langfuse_public_key, langfuse_secret_key, langfuse_host y langfuse_environment, con lista blanca en initialize_dynamic_callback_params.py:67. El gateway cachea un registrador por juego de credenciales (langfuse_handler.py:24) y, en la vía OTLP, construye un exportador completo por clave (langfuse_otel.py:400).

Es decir: un proyecto de Langfuse por equipo de LiteLLM es posible hoy, sin licencia, y es la forma correcta de aislar trazas entre inquilinos. Lo que no existe es la creación automática del proyecto, ni la correspondencia entre el equipo y el proyecto. Eso es pegamento que hay que escribir.

La ruta de ingesta

Langfuse acepta únicamente OTLP sobre HTTP, en http/protobuf o http/json. gRPC no está soportado. La ruta base es /api/public/otel y la señal vive en /api/public/otel/v1/traces, verificado en el repositorio. La autenticación es Basic con el par de claves del proyecto, más la cabecera x-langfuse-ingestion-version: 4 para la ruta de la versión 4.

El gateway lo construye exactamente así (langfuse_otel.py:328, :347, :359) y luego normaliza el endpoint añadiendo el sufijo de la señal (opentelemetry.py:3237). El resultado coincide con la ruta real, así que la integración funciona sin tocar nada. El detalle importa cuando se mete un colector en medio y alguien copia el endpoint a mano.

Y el aviso de calendario que ya salió en el par operativo sigue en pie: el callback clásico está atado al SDK v2 y la fecha marcada es el 16 de noviembre de 2026. Con un matiz que conviene leer antes de programar una migración de urgencia, y que se detalla en el artículo del modelo de datos: esa fecha rige para Langfuse Cloud, y en el código de la versión self-hosted la ruta antigua no se apaga, cambia de comportamiento según el modo de escritura.

Cuándo meter un colector

Directo si Langfuse es el único destino de trazas. Vía colector si hay más de un consumidor, o si hace falta alguna de estas tres cosas que el procesador de lotes del proxy no da:

Reintentos con espera creciente y cola en disco, con los procesadores sending_queue y file_storage. Con eso, una ventana de mantenimiento de Langfuse deja de perder trazas.
Muestreo de cola, que permite quedarse con el 100 % de los errores y el 1 % del resto. El proxy no puede muestrear por resultado, porque cuando decide ya no sabe cómo acabó.
Redacción de atributos antes de que salgan del espacio de nombres. Es la única capa donde se pueden borrar los argumentos de herramienta MCP que, como ya se documentó, se escriben en claro saltándose el interruptor de redacción de mensajes.

Costura 5. Postgres, Redis y la política de memoria

Postgres separado, siempre. Cada pieza aplica sus propias migraciones de Prisma sobre el esquema público de la base que se le indique. Dos clientes de Prisma migrando el mismo esquema colisionan por nombre de tabla y por historial de migraciones. Además Langfuse 4.x exige Postgres 15 como mínimo, recomienda 16 y quiere UTC por defecto. El perfil de carga también es opuesto: el gateway escribe registros de gasto a alta frecuencia, mientras que Langfuse hace transaccional ligero porque los datos de traza van a ClickHouse.

Redis separado, y el argumento no es el que parece. No hay colisión de claves por diseño: el gateway usa etiquetas de hash con la forma {api_key:...}:requests y un espacio de nombres opcional, y Langfuse usa el prefijo de BullMQ más un prefijo propio para su caché de claves. El argumento decisivo es otro: Langfuse exige maxmemory-policy=noeviction porque sus colas son datos, no caché, mientras que el gateway asume caché desechable. Compartir instancia significa que un pico de claves de límite de tasa puede llenar la memoria y provocar errores de escritura en las colas de ingesta en lugar de un desalojo inofensivo.

Si aun así se comparte, dos medidas mínimas: REDIS_KEY_PREFIX en Langfuse, namespace en el gateway, y bases lógicas distintas.

Y un recordatorio de superficie: Langfuse 4.x no arranca sin ClickHouse ni sin bucket compatible con S3. CLICKHOUSE_URL y LANGFUSE_S3_EVENT_UPLOAD_BUCKET son obligatorios y sin valor por defecto (packages/shared/src/env.ts:120 y :271). Su superficie de fallo es mucho mayor que la del gateway, y eso cambia dónde poner el esfuerzo de alta disponibilidad.

Puertos, para la NetworkPolicy

Pieza	Puerto
LiteLLM (API, interfaz y métricas)	4000
Langfuse web	3000
Langfuse worker	3030
ClickHouse	8123 HTTP, 9000 nativo
Almacenamiento S3 compatible	9000
Redis	6379
Postgres	5432
Colector OTel	4317 gRPC, 4318 HTTP

Los pares que hay que permitir con una política de denegación por defecto, siguiendo el método de hardening del stack:

litellm → postgres:5432, redis:6379
litellm → collector:4318 (o langfuse-web:3000 si va directo)
litellm → vllm:8000
litellm → keycloak:8443 (solo interfaz y flujo JWT)
collector → langfuse-web:3000
langfuse-web → postgres:5432, redis:6379, clickhouse:8123, s3:9000
langfuse-worker→ postgres:5432, redis:6379, clickhouse:8123, s3:9000
langfuse-web → keycloak:8443
ingress → litellm:4000, langfuse-web:3000
prometheus → litellm:4000

El worker de Langfuse no necesita tráfico de entrada más allá de la sonda de salud.

El pegamento que hay que escribir

Puesto en una tabla, el estado real de la cadena de inquilinos:

Tramo	¿Automático?	Cómo
Keycloak → equipo de LiteLLM	Sí	`team_ids_jwt_field` más `team_id_upsert: true`
Keycloak → usuario de LiteLLM	Sí	`user_id_jwt_field` más `user_id_upsert: true`
Keycloak → organización de Langfuse	No	Solo asignación estática al alta
Keycloak → proyecto de Langfuse	No	Igual
Equipo de LiteLLM → proyecto de Langfuse	No	`callback_vars` a mano, o un operador propio
Usuario de Keycloak → `user_id` de la traza	No	`end_user_id_jwt_field`, o contrato con el cliente

La arquitectura mínima viable sin licencia, entonces, es esta:

Un proyecto de Langfuse por inquilino, creado con las variables de inicialización desde GitOps.
Las claves de ese proyecto en un secreto de Kubernetes.
Un trabajo periódico propio que lea los equipos por la API de administración del gateway y escriba callback_vars con las claves correspondientes.
Las personas entrando a Langfuse por Keycloak, pero asignadas a mano a su organización.
El identificador de usuario final resuelto por contrato con los clientes, y validado.

Son unas ciento cincuenta líneas de código propio. Conviene presupuestarlas desde el principio, porque el hueco no se cierra solo.

Configuración de referencia

general_settings:
 # solo con licencia; sin ella, claves virtuales
 enable_jwt_auth: true
 litellm_jwtauth:
 team_ids_jwt_field: "groups"
 team_id_upsert: true
 user_id_jwt_field: "sub"
 user_id_upsert: true
 end_user_id_jwt_field: "preferred_username"
 user_allowed_email_domain: "ejemplo.es"
 admin_jwt_scope: "litellm_proxy_admin"
 # los tres que vienen apagados de fábrica
 enforce_rbac: true
 enforce_scope_based_access: true
 enforce_team_based_model_access: true
 allow_requests_on_db_unavailable: false
 proxy_batch_write_at: 60

litellm_settings:
 callbacks: ["langfuse_otel", "prometheus"]
 # sin esto, el motor no sabe quién llama
 add_user_information_to_llm_headers: true
 turn_off_message_logging: true
 cache: true
 cache_params:
 type: redis
 host: os.environ/REDIS_HOST
 namespace: litellm

# las dos que activan la validación que por defecto no ocurre
JWT_AUDIENCE=litellm-gateway
JWT_ISSUER=https://sso.ejemplo.es/realms/plataforma
JWT_PUBLIC_KEY_URL=https://sso.ejemplo.es/realms/plataforma/.well-known/openid-configuration

LANGFUSE_HOST=http://langfuse-web.observabilidad.svc:3000
LANGFUSE_PUBLIC_KEY=...
LANGFUSE_SECRET_KEY=...

Y del lado de Langfuse:

AUTH_KEYCLOAK_CLIENT_ID=langfuse
AUTH_KEYCLOAK_ISSUER=https://sso.ejemplo.es/realms/plataforma
AUTH_KEYCLOAK_ALLOW_ACCOUNT_LINKING=true
AUTH_DISABLE_USERNAME_PASSWORD=true
AUTH_DISABLE_SIGNUP=true
LANGFUSE_DEFAULT_ORG_ID=plataforma
LANGFUSE_DEFAULT_ORG_ROLE=VIEWER
ENCRYPTION_KEY=... # 64 caracteres hexadecimales

Checklist

Definir JWT_AUDIENCE y JWT_ISSUER el primer día, o usar la configuración por emisor. Sin eso no se valida ni audiencia ni emisor.
Poner enforce_rbac, enforce_scope_based_access y enforce_team_based_model_access en cierto, y probar que un token de otro cliente del mismo realm es rechazado.
Decidir de dónde sale el usuario final de las trazas y escribirlo en el diseño. Si no se decide, las trazas salen sin persona.
Separar Postgres. Separar Redis. Si se comparte Redis, prefijo y base lógica distintos, y revisar la política de memoria.
Comprobar que el proxy arranca con Postgres caído solo si eso es lo que se quiere, y que el equipo de guardia sabe distinguir un 503 de admisión de un 401 de credencial.
Alertar sobre litellm_service_latency por servicio, no sobre la disponibilidad de Redis, porque el cortacircuitos oculta el problema.
Un proyecto de Langfuse por inquilino con las variables de inicialización, y las claves por equipo en callback_vars.
Meter un colector en medio si hace falta cola en disco, muestreo de cola o redacción de atributos.
Revisar que la versión del gateway está por encima de 1.83.14 por las vulnerabilidades críticas anteriores.
Escribir en el análisis de riesgos que las claves virtuales son credenciales desacopladas del proveedor de identidad, y definir el procedimiento de baja.

Trampas y cosas que no son lo que parecen

Un JWT bien firmado no es un JWT dirigido a este servicio. Sin las dos variables de entorno, la audiencia no se comprueba.

enforce_rbac en falso no significa que no haya autorización, significa que la autorización la aporta solo la pertenencia a equipo, si hay claim de equipo. Sin claim de equipo y sin el flag, un token válido llega a /chat/completions.

La copia caducada de las claves públicas dura hasta setenta minutos, sumando los dos TTL. Revocar una clave en el proveedor no surte efecto inmediato.

Con una sola clave en el JWKS y sin identificador de clave, no se comprueba el identificador.

El usuario de la traza lo pone el cliente. Cualquier informe de gasto por persona construido sobre ese campo es una declaración, no una medida.

La caída de Redis no genera errores, genera límites por pod. Es el fallo más caro de los que no avisan.

Langfuse no arranca sin ClickHouse ni sin bucket S3. Su superficie de fallo es mayor que la del gateway, y eso cambia el reparto del esfuerzo de alta disponibilidad.

El control de acceso por proyecto de Langfuse es de pago en self-hosted, igual que los registros de auditoría. Para un expediente de ENS, eso se decide antes de montar, no después.

Compartir Redis no rompe por colisión de claves, rompe por política de memoria. Es un fallo que aparece bajo carga y que se diagnostica mal.

La ruta de ingesta de Langfuse es solo OTLP sobre HTTP. Un colector configurado con el exportador gRPC apunta a un sitio que no existe.

Cierre

Las cinco costuras tienen un patrón común: fallan sin avisar. El token de otro servicio entra, el usuario de la traza viene del cliente, el límite de tasa deja de ser global, la cola de gasto descarta al llegar a 64 MB y el proyecto de Langfuse no se crea solo. Ninguna de esas cinco cosas produce un error visible.

El trabajo del día 2, entonces, consiste sobre todo en convertir silencios en señales. Dos variables de entorno para que la audiencia se valide, tres flags para que la autorización sea real, una alerta sobre la latencia de servicio en lugar de sobre la disponibilidad de Redis, y un contrato explícito sobre de dónde sale la identidad del usuario final.

Y una decisión que conviene tomar pronto, antes de que el presupuesto esté cerrado. La autenticación por JWT del gateway y el control de acceso por proyecto de Langfuse están los dos detrás de licencia. Una plataforma soberana puede vivir perfectamente sin ambas, con claves virtuales y un proyecto por inquilino, pero es una arquitectura distinta y hay que dibujarla como tal desde el principio.

Ver también

LiteLLM y Langfuse: el par operativo: la costura entre gateway y trazas, con las cuatro colas que descartan.
Dimensionar para agentes: el artículo anterior del track, con el tamaño de cada pieza.
Keycloak en una plataforma de IA: la pieza de identidad por dentro y su posición en la arquitectura.
El gateway MCP de LiteLLM: la segunda puerta, con sus permisos y su problema de privacidad.
Langfuse por dentro y qué entra en una traza.
Hardening y secretos del stack LLM soberano: el método de denegación por defecto que ordena la tabla de puertos.
Cuando el MCP crece: ponerle autenticación con Keycloak.

Fuentes

Código de LiteLLM 1.102.0, commit 9071ca50 del 11 de septiembre de 2026.
Código de Langfuse 4.35.0, commit 39e3cd7d del 11 de septiembre de 2026.
Autenticación y SSO en Langfuse, consultado el 12 de septiembre de 2026.
SCIM y API de organización, consultado el 12 de septiembre de 2026.
Integración OpenTelemetry de Langfuse, consultado el 12 de septiembre de 2026.
Postgres y caché en la documentación de self-hosting, consultados el 12 de septiembre de 2026.
Autenticación por token en LiteLLM y ajustes de configuración, consultados el 12 de septiembre de 2026.
GHSA-jjhc-v7c2-5hh6 y registro de CVE-2026-35030 en NVD.

Identidad on lo0 — Blog Técnico

Completar Keycloak para MCP: el recurso protegido que ningún SDK te da hecho, y la extensión empresarial que se salta el flujo entero

TL;DR

Estás aquí: el lado del recurso

La analogía: el visado y el control de frontera

Parte 1. El reparto de obligaciones

Novedades de la revisión que afectan al montaje

Parte 2. Lo que los SDK dan, y lo que no

Los metadatos de recurso protegido

La validación de audiencia

El reto de autenticación

Los ámbitos, que no son por herramienta

Qué revisión anuncia cada uno

Parte 3. Construir el recurso protegido

Parte 4. El salto del gateway al servidor MCP

Lo que hace hoy el gateway

Parte 5. La extensión empresarial, que cambia el dibujo

Y aquí viene el problema

Lo que ya está en el gateway, sin documentar

Parte 6. La autorización por herramienta

Parte 7. Lo que sigue sin estándar

Parte 8. Quién cubre qué

Configuración de referencia

Checklist

Trampas y cosas que no son lo que parecen

Cierre

Ver también

Fuentes

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

TL;DR

Estás aquí: la capa transversal

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

Parte 1. Qué es Keycloak hoy

Estado del proyecto

La arquitectura interna en cinco piezas

El modelo conceptual mínimo

Parte 2. Quién puede autenticarse contra él

Parte 3. Humanos y máquinas

Personas

Cargas sin persona detrás

Keycloak frente a SPIFFE

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

Lo que exige la especificación

Lo que soporta Keycloak

Parte 5. El delegado confuso

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

Parte 7. Dimensionar y operar

En Kubernetes

Las cifras oficiales de dimensionado

El banco de pruebas

Seguridad

Parte 8. El mapeo al ENS

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

Parte 10. Lo que Keycloak no resuelve

Antipatrones

Checklist de arranque

Cierre

Ver también

Fuentes

El gateway no vive solo: el JWT que no valida la audiencia, el usuario que nunca llega a la traza y las costuras que hay que escribir a mano

TL;DR

Estás aquí: entre las cuatro piezas

La analogía: la obra con cinco gremios

Costura 1. Qué tumba y qué degrada

Postgres

Redis

Los callbacks

Costura 2. Identidad: las tres puertas y lo que valida cada una

Lo primero que hay que saber: es de pago

Los campos de litellm_jwtauth que deciden la seguridad

La validación que no ocurre

Del claim al permiso

La vulnerabilidad que conviene conocer

Costura 3. La identidad no llega a la traza

Costura 4. Langfuse como vecino

Lo que se puede automatizar y lo que no

El arranque declarativo, que sí existe

Credenciales de Langfuse por equipo

La ruta de ingesta

Cuándo meter un colector

Los campos de `litellm_jwtauth` que deciden la seguridad