Cuando el MCP crece: ponerle autenticación con Keycloak

Thu, 18 Jun 2026 08:30:00 +0200

Cuando un hijo es pequeño, basta con vigilar que no se haga daño. Le pones una valla en la escalera, tapas los enchufes y poco más. Pero el niño crece. Empieza a salir solo, a manejar dinero, a tomar decisiones que tienen consecuencias. Y entonces la educación deja de ser «que no se caiga» para convertirse en algo mucho más exigente: enseñarle a identificarse, a pedir permiso, a saber hasta dónde puede llegar y a rendir cuentas de lo que hace.

Con nuestros servidores MCP nos ha pasado exactamente eso.

El MCP ya no es un juguete

Hace nada, un servidor Model Context Protocol era un experimento que corría en el portátil de alguien para que un modelo pudiera leer un par de ficheros o llamar a una API interna. Daba igual quién lo usara: éramos nosotros, en local, sin nada en juego.

Eso se acabó. Los MCP se han vuelto piezas de infraestructura que la IA usa para tocar sistemas de verdad. Y, como cualquier hijo que crece, han desarrollado necesidades nuevas que antes no tenían:

Multitenancy: ya no hay un único usuario, sino muchos, y lo de uno no puede ser visible para otro.
Control de costes: cada llamada del modelo consume tokens, cómputo y, a veces, APIs de pago. Hay que medir, atribuir y poner límites.
Autenticación y autorización: saber quién está al otro lado, qué permisos tiene y para qué servidor concreto vale su credencial.

Son tres frentes distintos. Hoy nos centramos en el tercero, que es el que abre la puerta a los otros dos: la autenticación. Sin saber quién llama, no hay tenant que separar ni coste que atribuir.

Por qué la autenticación del MCP es un problema con nombre propio

La buena noticia es que aquí no hay que inventar nada. La especificación de MCP no se sacó de la manga un mecanismo de seguridad propio: se apoya en OAuth, el mismo estándar que lleva años detrás del «Iniciar sesión con…» de medio internet. El MCP define cómo un servidor MCP actúa de recurso protegido y delega la emisión de credenciales en un servidor de autorización.

Y ese servidor de autorización puede ser Keycloak, el gestor de identidades open source de la Cloud Native Computing Foundation que probablemente ya tengas montado para el resto de tus aplicaciones. La idea es no añadir un silo de identidad más solo porque ahora hablamos con modelos: reutilizar el que ya gobierna a tus usuarios.

El matiz importante es que MCP no es un único estándar congelado, sino una especificación viva con varias versiones, y cada una pide cosas distintas. A día de hoy conviven cuatro:

2025-11-25 (la última)
2025-06-18
2025-03-26
2024-11-05 (la inicial, que ni siquiera contemplaba autorización)

Igual que con la educación de un hijo no es lo mismo lo que necesita a los 6 años que a los 16, lo que Keycloak tiene que cumplir depende de la versión de MCP con la que trabajes. Veámoslo.

Qué le exige MCP a un servidor de autorización (y qué cumple Keycloak)

La especificación enumera una serie de estándares OAuth que el servidor de autorización debe soportar, con distintos niveles de exigencia (MUST, SHOULD, MAY). Esta es la foto, cruzada con lo que Keycloak soporta:

Estándar	2025-11-25	2025-06-18	2025-03-26	Keycloak
OAuth 2.1 Authorization Framework (borrador)	MUST	MUST	MUST	Soportado
OAuth 2.0 Authorization Server Metadata (RFC 8414)	MUST	MUST	MUST	Soportado
Resource Indicators for OAuth 2.0 (RFC 8707)	MUST	MUST	—	No soportado
Dynamic Client Registration (RFC 7591)	MAY	SHOULD	SHOULD	Soportado
OAuth Client ID Metadata Document (borrador)	SHOULD	—	—	Soportado (experimental)

Una aclaración: MCP también adopta OAuth 2.0 Protected Resource Metadata (RFC 9728), pero ese estándar es cosa del servidor MCP, no del servidor de autorización, así que no entra en la tabla de Keycloak.

Si tomamos como criterio de conformidad que Keycloak «soporta» una versión cuando cumple todos sus MUST y SHOULD, el resultado es este:

Versión MCP	Conformidad
`2025-03-26`	Soportada
`2025-06-18`	Parcial, sin Resource Indicators (RFC 8707)
`2025-11-25`	Parcial, sin Resource Indicators (RFC 8707)

La única pieza que hoy le falta a Keycloak es Resource Indicators for OAuth 2.0 (RFC 8707), el parámetro resource que ata un token a un servidor concreto. La comunidad de Keycloak ya tiene en hoja de ruta soportarlo; mientras tanto, hay un rodeo perfectamente válido que vemos más abajo. Es, siguiendo la analogía, esa asignatura que al niño aún se le resiste pero que se puede aprobar con un truco de estudio hasta que madure del todo.

Manos a la obra: montar Keycloak según tu versión de MCP

Para MCP 2025-03-26

No hay que configurar nada especial. Esta versión no exige el parámetro resource, así que Keycloak cumple de serie. El hijo todavía es pequeño y la valla en la escalera basta.

Para MCP 2025-06-18 y 2025-11-25: atar el token a su audiencia

Aquí empieza lo interesante. Por seguridad, estas versiones exigen que un token de acceso esté ligado a la audiencia para la que se emitió. En cristiano:

El cliente MCP debe incluir el parámetro resource (de RFC 8707) en la petición de autorización y de token, con el valor que identifica al servidor MCP que va a usar.
El servidor MCP debe validar que los tokens que recibe se emitieron específicamente para él.

Esto evita que un token robado o reutilizado sirva para entrar en un servidor distinto del previsto. El problema, como decíamos, es que Keycloak todavía no entiende el parámetro resource.

La solución mientras llega el soporte nativo de RFC 8707 es usar el parámetro scope de OAuth para conseguir el mismo efecto. Imaginemos esta situación:

El servidor MCP está en https://example.com/mcp.
Soporta tres scopes: mcp:tools, mcp:prompts y mcp:resources.
El cliente pide un token con resource = https://example.com/mcp y una combinación de esos scopes.
Queremos que Keycloak emita un token cuyo aud (audiencia) sea precisamente https://example.com/mcp.

Para lograrlo, configuramos Keycloak así, repitiendo el patrón para cada scope:

Crea un client scope mcp:tools de tipo Optional y añádele un Audience mapper cuyo Included Custom Audience sea https://example.com/mcp.
Crea un client scope mcp:prompts de tipo Optional con su Audience mapper apuntando a https://example.com/mcp.
Crea un client scope mcp:resources de tipo Optional con su Audience mapper apuntando a https://example.com/mcp.

La clave es que el Included Custom Audience de cada client scope sea idéntico al valor del parámetro resource de la petición y a la URL del servidor MCP. Con esto, si el cliente pide un token con esos tres scopes, Keycloak emite algo como:

{
 "aud": "https://example.com/mcp",
 "scope": "mcp:resources mcp:tools mcp:prompts"
}

El servidor MCP ya puede comprobar el aud y rechazar cualquier token que no fuera para él. Hemos atado la credencial a su destinatario sin esperar a RFC 8707.

Si usas MCP Inspector

MCP Inspector es la herramienta oficial para depurar servidores MCP, y registra clientes dinámicamente contra Keycloak ejecutando JavaScript desde su backend. Para que funcione hay que ajustar CORS en las anonymous access policies del registro de clientes:

Allowed Client Scopes: incluir los scopes que soporta tu servidor MCP.
Allowed Registration Web Origins: incluir el origen web del backend de MCP Inspector.
Trusted Hosts: incluir el host o IP de la máquina que envía la petición de registro dinámico, es decir, donde corre tu navegador.

Para MCP 2025-11-25: registro de clientes con Client ID Metadata Document

La última versión añade un capítulo nuevo: cómo se registran los clientes. Contempla tres enfoques, y eliges según tu escenario:

Client ID Metadata Documents: cuando cliente y servidor no se conocen de antes (el caso más común).
Pre-registro: cuando ya existe una relación previa.
Dynamic Client Registration: para compatibilidad hacia atrás o requisitos concretos.

Keycloak soporta el primero, OAuth Client ID Metadata Document (CIMD), aunque conviene saber que es una función experimental: puede traer cambios incompatibles en versiones futuras. Para activarla, arranca Keycloak con el flag:

bin/kc.sh start --features=cimd

La idea de CIMD es que el client_id deja de ser un identificador opaco y pasa a ser una URL que apunta a un documento con los metadatos del cliente. Keycloak descarga ese documento y procesa la petición con lo que encuentre. Para que lo haga, hay que crear un client policy profile y una policy que lo disparen.

Perfil (profile). En Realm Settings → Client Policies → Profiles, crea un perfil (p. ej. cimd-profile), añade el ejecutor client-id-metadata-document y configúralo:

Allow http scheme: permite http para las URLs (client_id, client_uri, logo_uri, jwks_uri, etc.). Solo en desarrollo; en producción OFF.
Trusted domains: patrones con comodín de dominios aceptados (p. ej. *.example.org). Si está vacío, se deniegan todos.
Restrict same domain: si está ON, exige que el client_id URL, el redirect_uri y las URLs de los metadatos estén todos bajo el mismo dominio de confianza.
Required properties: propiedades que el documento de metadatos debe incluir obligatoriamente.
Only Allow Confidential Client: si está ON, solo acepta clientes confidenciales (con jwks/jwks_uri y autenticación private_key_jwt o tls_client_auth).

Política (policy). En Realm Settings → Client Policies → Policies, crea una policy (p. ej. cimd-policy), añade la condición client-id-uri y configúrala:

URI scheme: esquemas a reconocer en el client_id (en producción, solo https).
Trusted domains: dominios aceptados en el host del client_id. Si se rellenan, la condición solo es verdadera cuando el host coincide; si se dejan vacíos, es siempre falsa.

Luego asocia el cimd-profile a esta policy. A partir de ahí, cuando llegue una petición con un client_id que sea una URL https de un dominio de confianza, Keycloak descarga el documento de metadatos y lo usa para procesar la petición.

Ajustes globales del ejecutor. Algunos parámetros no están en la consola y se pasan como opciones SPI al arrancar:

min-cache-time: tiempo mínimo de caché del documento (por defecto 300 s).
max-cache-time: tiempo máximo de caché (por defecto 259200 s, 3 días).
upper-limit-metadata-bytes: tamaño máximo del documento (por defecto 5000 bytes).

bin/kc.sh start \
 --spi-client-policy-executor--client-id-metadata-document--min-cache-time=600 \
 --spi-client-policy-executor--client-id-metadata-document--max-cache-time=86400 \
 --spi-client-policy-executor--client-id-metadata-document--upper-limit-metadata-bytes=10000

Caso real: VS Code desktop como cliente MCP

Visual Studio Code es un cliente MCP que usa CIMD. Cuando se conecta a un servidor MCP que requiere autorización, manda un client_id que es una URL https alojada en vscode.dev (p. ej. https://vscode.dev/mcp-client), y Keycloak descarga de ahí sus metadatos. El detalle a tener en cuenta es que VS Code es un cliente público que usa PKCE (sin secreto de cliente) y, para el callback de OAuth, levanta un servidor local con un redirect_uri tipo http://127.0.0.1:<puerto>/callback. Como ese redirect no está en el dominio de vscode.dev, hay que dejar Restrict same domain en OFF.

Arranca con --features=cimd y configura:

Perfil vscode-cimd-profile (ejecutor client-id-metadata-document):

Allow http scheme: OFF
Trusted domains: vscode.dev, 127.0.0.1
Restrict same domain: OFF (el redirect es un localhost, no vscode.dev)
Only Allow Confidential Client: OFF (VS Code es público)

Política vscode-cimd-policy (condición client-id-uri):

URI scheme: https
Trusted domains: vscode.dev
Asocia el perfil vscode-cimd-profile.

Con esto, cuando VS Code lance la petición, Keycloak reconoce el client_id como una URL de vscode.dev, descarga el Client ID Metadata Document y completa el flujo OAuth con el callback en localhost.

La educación continúa

Hemos enseñado a nuestro MCP a identificarse y a pedir permiso de forma estándar, reutilizando la identidad que ya gobierna Keycloak en el resto de la casa. No es poca cosa: con un token bien atado a su audiencia, lo demás empieza a ser posible.

Pero, como con cualquier hijo que crece, esto no termina aquí. Quedan pendientes las otras dos asignaturas que mencionábamos al principio —separar a los inquilinos (multitenancy) y controlar lo que gasta (costes)— y a Keycloak todavía le falta madurar en algún punto, como el soporte nativo de Resource Indicators. Iremos cubriéndolas en próximos artículos. Por ahora, nuestro MCP ya sabe decir quién es. Y eso, en seguridad, es el primer día de colegio.

OAuth on lo0 — Blog Técnico