Inside the Harness: la vinculación de issuer OAuth en MCP y por qué la seguridad de protocolos vive en comparar strings

Tres números y luego los explico. Uno: el campo issuer de un documento de metadatos OAuth es un solo string. Dos: este verano Atlassian, Context7 y Home Assistant han servido metadatos de autorización MCP donde ese string no coincidía con la URL desde la que se obtuvo, y los clientes estrictos se negaron a conectar. Tres: el arreglo que ahora entra en la especificación MCP es, en esencia, "compara el string y rechaza si difiere". Ese es todo el mecanismo, y el ataque que cierra es uno de los más desagradables de OAuth: el mix-up attack, empeorado estructuralmente por la forma en que MCP se despliega.

Este es un artículo de Inside the Harness, así que vamos a entrar en la fontanería: qué es el problema de issuer binding, qué flows afecta y qué exige el paquete de especificación 2026-07-28 a cualquiera que construya un cliente o servidor MCP. Los cambios de transporte stateless de la misma versión se llevaron los titulares; el endurecimiento de auth recibió seis SEPs y casi ninguna cobertura. Está al revés, porque si ejecutas servidores MCP con credenciales reales, esta es la parte que decide si un cliente confundido entrega un token a la parte equivocada.

Conclusiones clave - MCP invierte la forma clásica de OAuth: un cliente hablando con muchos authorization servers, descubiertos en runtime. Esa inversión es exactamente la topología para la que se diseñaron los mix-up attacks. - El paquete de especificación 2026-07-28 son seis SEPs. Las dos más importantes: SEP-2468, que valida el parámetro iss en authorization responses según RFC 9207, y SEP-2352, que vincula cada client credential registrado con el issuer que lo emitió. - No es teórico. Los endpoints MCP de Atlassian y Context7 han servido este verano metadatos con issuer mismatch, rompiendo clientes estrictos; la especificación está alcanzando fallos ya presentes en producción. - La validación de iss está recomendada ahora y camina hacia ser obligatoria. Impleméntala hoy y trata la ausencia de iss en un servidor que debería soportarlo como rechazo, no como indiferencia. - Incluso adoptado por completo, este paquete solo endurece la autenticación cliente-servidor. Identidad del agente, autorización por request, procedencia de delegación y auditoría siguen fuera del protocolo, a tu cargo.

Qué ocurrió

El 21 de mayo de 2026 los mantenedores de MCP bloquearon el release candidate de la especificación 2026-07-28, la especificación final salió el 28 de julio y los mantenedores de SDK llevan desde entonces en una ventana de validación de diez semanas. La mayoría de los comentarios se centraron en el cambio stateless. Debajo, según la lectura detallada de Tigera, hay un paquete de seis Spec Enhancement Proposals endureciendo la capa OAuth:

Las tres SEPs de housekeeping, 2207, 2350 y 2351, son aclaraciones, y las aclaraciones en especificaciones de auth importan: dos SDKs que no coinciden sobre dónde vive un documento de metadatos provocan una caída de interoperabilidad, no una nota al pie. Pero el par estructural es 2468 y 2352, ambas sobre la misma pregunta: ¿cómo sabe un cliente con qué servidor está hablando realmente?

El paquete de especificación MCP 2026-07-28 contiene seis SEPs de endurecimiento OAuth: validación de issuer (2468), credenciales vinculadas a issuer (2352), declaración de tipo de cliente en Dynamic Client Registration (837), además de refresh tokens documentados (2207), acumulación de scopes (2350) y comportamiento de discovery (2351), según el análisis de Tigera. El release candidate se bloqueó el 21 de mayo y la especificación final salió el 28 de julio de 2026.

El modelo de vulnerabilidad: un cliente, muchos issuers

OAuth clásico supone muchos clientes y un authorization server: miles de apps, un identity provider, un token issuer. Los mix-up attacks, donde se engaña a un cliente para que atribuya una authorization response al servidor equivocado, eran una preocupación de nicho porque la mayoría de los clientes solo hablaban con un issuer.

MCP lo ejecuta al revés. Un cliente, la aplicación host, habla con muchos servidores MCP, cada uno potencialmente detrás de un authorization server diferente, descubierto en runtime y muchas veces registrado al vuelo mediante Dynamic Client Registration. Los autores de la especificación lo dicen directamente: el SEP de issuer validation apunta a "a class of mix-up attack that is more prevalent in MCP's single-client, many-server deployment pattern", como cita el artículo de Tigera. Cuando tu cliente mantiene registros con una docena de authorization servers a la vez, el atacante no necesita romper criptografía. Necesita que tu cliente atribuya una respuesta al servidor incorrecto.

La forma es esta. El host de tu agente está a mitad de flow con el servidor honesto A cuando llega una respuesta que realmente viene del servidor B controlado por el atacante. Sin comprobar issuer, el cliente puede completar el exchange contra B, filtrando el authorization code, o aceptar tokens emitidos por B y presentarlos después. RFC 9207, el arreglo de 2021 para OAuth clásico, añadió un parámetro explícito iss a authorization responses para que el cliente rechace cualquier cosa de un issuer inesperado, y SEP-2468 lleva ese requisito a MCP. SEP-2352 cubre la mitad más silenciosa: credenciales. Antes, un cliente podía tener un client ID emitido por issuer A y, cuando un recurso migraba a issuer B, presentar la credencial de A a B. A veces funcionaba, y "a veces funciona" no es una propiedad que quieras en un sistema de auth. Por eso 2352 exige guardar los registros por authorization server, vinculados al valor issuer, y volver a registrar al migrar.

Tampoco es el primer intento sobre esta clase. La revisión de especificación 2025-06-18 hizo obligatorios los Resource Indicators de RFC 8707 para que los tokens se emitan para un servidor específico, y la especificación de autorización MCP ya prohíbe aceptar tokens destinados a otros recursos o pasarlos downstream. El paquete 2026-07-28 continúa la misma trayectoria: menos confianza por defecto, más binding explícito. Si has leído mi artículo MCP versus API, este es el coste de la flexibilidad que describí: runtime discovery hace MCP componible y también fabrica estas preguntas de identidad.

La topología un-cliente-muchos-servidores de MCP es exactamente el patrón de despliegue que atacan los mix-up attacks: un atacante no rompe la criptografía, consigue que el cliente atribuya una respuesta o credencial al authorization server equivocado. SEP-2468 vincula responses con issuers mediante el parámetro iss de RFC 9207; SEP-2352 vincula credenciales registradas al servidor que las emitió, según el análisis de Tigera y RFC 9207.

La especificación está alcanzando fallos de producción

Si esto suena abstracto, no lo es. El string issuer ha estado fallando en despliegues MCP reales todo el verano, y los clientes estrictos ya se están topando con ello.

En julio, usuarios del cliente opencode encontraron que OAuth hacia el servidor MCP Rovo de Atlassian fallaba en discovery. Los metadatos protected-resource anunciaban correctamente un authorization server específico del tenant, pero el documento servido allí declaraba el issuer compartido https://auth.atlassian.com en vez de la ruta tenant desde la que se obtuvo. RFC 8414 sección 3.3 dice que el valor issuer debe ser exactamente igual a la URL utilizada para recuperar los metadatos, menos el sufijo .well-known, por lo que la validación estricta de opencode lo rechazó correctamente y bloqueó el login por completo: un bug de cumplimiento de especificación del lado de Atlassian, confirmado contra endpoints live. El endpoint MCP de Context7 tuvo un bug hermano en junio, donde el authorization server anunciado y el metadata issuer en un subdominio Clerk no coincidían, y el SDK Go oficial de MCP rechazó el flow. Los metadatos de Home Assistant omitían por completo el campo issuer, rompiendo clientes MCP de otra forma.

Ninguno de los tres fue un exploit mix-up; fueron fallos de interoperabilidad. Pero ese es precisamente el punto. La misma comparación de string que bloquea el servidor falso de un atacante también bloquea uno real mal configurado, así que el ecosistema está a punto de tolerar mucho menos los metadatos que siempre estuvieron mal y antes pasaban. El artículo de WorkOS sobre mix-up attacks explica bien la parte operativa: muchas librerías OAuth todavía dejan desactivada por defecto la comprobación RFC 9207, y señala CVE-2026-59208 como caso donde limitar los account lookups al issuer confirmado, en vez de comparar un claim sub globalmente, habría detenido el bug. Trataría esa referencia CVE como reportada por WorkOS y no verificada independientemente, pero el principio defensivo es práctica estándar de todos modos.

Despliegues MCP reales han fallado issuer validation todo el verano: el servidor MCP Rovo de Atlassian sirve metadatos cuyo issuer no coincide con la URL tenant desde la que se obtuvieron (opencode issue #39332), el endpoint de Context7 anunció un authorization server mientras sus metadatos declaraban otro (Context7 issue #2723), y Home Assistant omitió por completo el campo issuer. RFC 8414 sección 3.3 exige que el issuer coincida exactamente con la retrieval URL, así que los clientes estrictos rechazaron correctamente los tres.

Qué deben hacer los implementadores

Si mantienes un cliente MCP:

1. Valida iss en cada authorization response desde ahora. Rechaza mismatches con el issuer con el que estás a mitad de flow, y si el servidor anuncia soporte RFC 9207 pero omite el parámetro, recházalo también. La especificación dice claramente que rechazar un iss ausente llegará en una versión futura, así que trátalo como obligatorio hoy.

2. Particiona el estado de registro por authorization server. Cada client ID, secret y refresh token se guarda contra el valor issuer que lo emitió. Si los metadatos protected-resource de un recurso empiezan a apuntar a un nuevo authorization server, vuelve a registrar; nunca reproduzcas la credencial anterior.

3. Declara application_type en Dynamic Client Registration. SEP-837 corrige la clase de fallos donde un cliente desktop o CLI se considera web por defecto y es rechazado por su redirect URI localhost. Un campo, una clase real de bugs eliminada.

4. Limita account lookups al issuer. Un claim sub solo debe hacer match con cuentas dentro del namespace del issuer que realmente validaste. Nunca hagas match global.

Si ejecutas un servidor MCP o un authorization server delante de uno: sirve metadatos cuyo issuer sea exactamente igual a la URL desde la que se recuperan, incluida la ruta tenant, implementa protected-resource metadata según RFC 9728 y sigue validando que los tokens se emitieron específicamente para tu recurso. Y si estás self-hosting agents contra una lista creciente de servidores MCP, las matemáticas de flota importan: N agents por M servers significa N por M registros vinculados a issuer. Con diez agents es una spreadsheet; con cien es un registry, y la especificación no opina sobre registries. Esa parte es de tu plataforma.

Los implementadores deben validar iss en authorization responses, rechazando mismatches y, donde se soporte, omisiones, almacenar credenciales particionadas por issuer y volver a registrar al migrar, declarar application_type durante Dynamic Client Registration y limitar account lookups al issuer validado, según el análisis SEP de Tigera y la guía de WorkOS sobre mix-up. Se espera que los SDK Tier 1 entreguen soporte dentro de la ventana de validación de diez semanas de la especificación.

Qué sigue sin responder la especificación

Lee el paquete otra vez y fíjate en lo que tienen en común las seis SEPs: endurecen el intercambio entre un cliente OAuth y un authorization server. Era necesario. Pero como dice claramente el análisis de Tigera, el token autentica al cliente, no al agente. Doscientos agentes detrás de un host comparten una client identity; issuer binding no dice nada sobre qué agente, en nombre de quién, decidiendo con base en qué, está detrás del cliente. Scopes son admisión, no policy por request. Cadenas de delegación, agente llama a agente llama a servidor, pueden ser OAuth-clean en cada salto y no tener accountability end-to-end. Y nada del paquete exige que nadie lo escriba, que es la decisión correcta de scope para un protocolo y una respuesta incompleta para una empresa.

No lo digo para restar valor al trabajo. MCP sin issuer validation era HTTP sin certificate checking, y ese agujero se está cerrando. Pero las cuatro brechas, agent identity, per-request authorization, delegation provenance y audit, son la capa de governance, y no aparecen esperando a la especificación. Son las mismas brechas que trabajo con clientes en agent governance, y las impone el entorno alrededor del agente o no las impone nadie.

FAQ

¿Cuál es el problema de OAuth issuer binding en MCP?

Los clientes MCP hablan con muchos authorization servers descubiertos en runtime, lo que los hace vulnerables a mix-up attacks: una response o credencial atribuida al servidor incorrecto. La especificación 2026-07-28 lo corrige exigiendo que los clientes validen el parámetro iss en authorization responses, SEP-2468 adoptando RFC 9207, y que vinculen cada credencial registrada con su issuer, SEP-2352.

¿Es una vulnerabilidad de MCP en sí?

Es una clase de vulnerabilidad que el patrón de despliegue del protocolo hizo más frecuente, y que ahora se cierra a nivel de especificación. Los fallos vistos en producción este verano, Atlassian, Context7 y Home Assistant sirviendo metadatos con issuer mismatch, fueron bugs de implementación, pero muestran lo frágil que era el modelo sin validación. La validación estricta es ahora la base.

¿Qué flows se ven afectados?

Authorization-code flows con cualquier cliente registrado contra más de un authorization server, Dynamic Client Registration entre servidores, uso de credenciales después de que un recurso migre entre authorization servers y metadata discovery mediante documentos .well-known. Los despliegues de un solo servidor nunca fueron el riesgo; lo es la topología multi-servidor que crean los agentes.

¿Cuándo se vuelve obligatorio?

La especificación 2026-07-28 es final, el soporte SDK está llegando dentro de una ventana de validación de diez semanas desde el bloqueo del release candidate de mayo, y la especificación es explícita en que rechazar responses sin iss se esperará en una versión futura. Trátalo como obligatorio en cualquier cosa que construyas ahora.

En resumen

La seguridad OAuth consiste en gran medida en aburridas comparaciones de strings con consecuencias, y MCP acaba de tener su ajuste de cuentas con ese hecho. El paquete 2026-07-28 importa un arreglo OAuth de hace cinco años a un protocolo cuya forma un-cliente-muchos-servidores lo convirtió en urgente, justo cuando despliegues reales empezaban a fallar esa comprobación en producción. Actualiza tus SDKs, valida iss, vincula tus registros. Luego haz la pregunta que la especificación hizo bien en no responder: cuando un token que emitiste se usa para una tool call que nunca habrías aprobado, presentado por un agente que no puedes nombrar, ¿quién lo detecta y dónde queda el registro? Esa respuesta no viene de una especificación. Viene del harness que construyes alrededor.

Si estás resolviendo auth e identidad para un deployment MCP, es una conversación que tengo con clientes con frecuencia. Ponte en contacto.

Fuentes

• Tigera, "MCP's Auth Hardening: What the Six New OAuth SEPs Fix, and What They Still Don't": https://www.tigera.io/blog/mcps-auth-hardening-what-the-six-new-oauth-seps-fix-and-what-they-still-dont/ (publicado 2026-07-28, consultado 2026-08-29)

• WorkOS, "OAuth mix-up attacks and RFC 9207: The issuer check that never made it to token exchange": https://workos.com/blog/oauth-mix-up-attacks-rfc-9207 (publicado 2026-07-20, consultado 2026-08-29)

• Model Context Protocol, Authorization specification: https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization (publicado 2025-11-25, consultado 2026-08-29)

• RFC Editor, RFC 9207, "OAuth 2.0 Authorization Server Issuer Identification": https://www.rfc-editor.org/rfc/rfc9207.html (publicado 2021-12-16, consultado 2026-08-29)

• opencode repository, issue #39332, "MCP OAuth: Atlassian auth fails - RFC 8414 issuer mismatch": https://github.com/anomalyco/opencode/issues/39332 (publicado 2026-07-28, consultado 2026-08-29)

• Context7 repository, issue #2723, "OAuth metadata issuer mismatch for MCP OAuth endpoint": https://github.com/upstash/context7/issues/2723 (publicado 2026-06-05, consultado 2026-08-29)

• Home Assistant Core, issue #147059, missing issuer in OAuth metadata: https://github.com/home-assistant/core/issues/147059 (publicado 2025-06-17, consultado 2026-08-29)

• modelcontextprotocol/modelcontextprotocol repository: https://github.com/modelcontextprotocol/modelcontextprotocol (consultado 2026-08-29)