Inside the Harness: o issuer binding OAuth do MCP e por que segurança de protocolo vive em comparação de strings

Três números, depois explico. Um: o campo issuer em um documento de metadata OAuth é uma única string. Dois: neste verão, Atlassian, Context7 e Home Assistant serviram metadata de autorização MCP em que essa string não correspondia à URL da qual o documento foi obtido, e clientes estritos se recusaram a conectar. Três: a correção agora chegando à especificação MCP é, no fundo, "compare a string, rejeite se for diferente". Esse é todo o mecanismo, e o ataque que ele fecha é um dos mais desagradáveis do OAuth: o mix-up attack, estruturalmente piorado pela forma como MCP é implantado.

Este é um texto Inside the Harness, então vamos para a tubulação: qual é o problema de issuer binding, quais flows ele afeta e o que o pacote de especificação 2026-07-28 exige de quem constrói um cliente ou servidor MCP. As mudanças de transporte stateless na mesma release ficaram com as manchetes; o hardening de auth ganhou seis SEPs e quase nenhuma cobertura. Está invertido, porque se você roda servidores MCP com credentials reais, esta é a parte que decide se um cliente confuso entrega token à parte errada.

Principais conclusões - MCP inverte o formato clássico de OAuth: um cliente falando com muitos authorization servers, descobertos em runtime. Essa inversão é exatamente a topologia para a qual mix-up attacks foram projetados. - O pacote de especificação 2026-07-28 contém seis SEPs. As duas mais importantes: SEP-2468, validar o parâmetro iss em authorization responses segundo RFC 9207, e SEP-2352, vincular toda client credential registrada ao issuer que a emitiu. - Não é teórico. Endpoints MCP da Atlassian e Context7 serviram metadata com issuer mismatch neste verão, quebrando clientes estritos; a especificação está alcançando falhas já presentes em production. - Validação de iss é recomendada agora e caminha para ser obrigatória. Implemente hoje e trate iss ausente de servidor que deveria suportá-lo como rejeição, não como indiferença. - Mesmo totalmente adotado, o pacote só endurece autenticação cliente-servidor. Agent identity, authorization por request, delegation provenance e audit continuam fora do protocolo, por sua conta.

O que aconteceu

Em 21 de maio de 2026, mantenedores do MCP travaram o release candidate da especificação 2026-07-28, a especificação final saiu em 28 de julho e mantenedores de SDK estão desde então em uma janela de validação de dez semanas. A maior parte dos comentários foi para a mudança stateless. Por baixo, segundo a leitura detalhada da Tigera, há pacote de seis Spec Enhancement Proposals endurecendo a camada OAuth:

As três SEPs de housekeeping, 2207, 2350 e 2351, são esclarecimentos, e esclarecimentos em especificação de auth importam: dois SDKs discordando sobre onde fica um documento de metadata produzem outage de interoperabilidade, não nota de rodapé. Mas o par estrutural é 2468 e 2352, ambos sobre a mesma pergunta: como o cliente sabe com qual servidor está realmente falando?

O pacote de especificação MCP 2026-07-28 contém seis SEPs de hardening OAuth: validação de issuer (2468), credentials vinculadas a issuer (2352), declaração do tipo de cliente em Dynamic Client Registration (837), além de refresh tokens documentados (2207), acumulação de scope (2350) e comportamento de discovery (2351), segundo a análise da Tigera. O release candidate foi travado em 21 de maio e a especificação final saiu em 28 de julho de 2026.

O modelo de vulnerabilidade: um cliente, muitos issuers

OAuth clássico pressupõe muitos clientes e um authorization server: milhares de apps, um identity provider, um token issuer. Mix-up attacks, em que o cliente é enganado para atribuir authorization response ao servidor errado, eram preocupação de nicho porque a maioria dos clientes falava com um único issuer.

MCP roda tudo ao contrário. Um cliente, a host application, fala com muitos servidores MCP, cada um potencialmente atrás de authorization server diferente, descoberto em runtime e frequentemente registrado na hora via Dynamic Client Registration. Os autores da especificação dizem diretamente: o SEP de issuer validation mira "a class of mix-up attack that is more prevalent in MCP's single-client, many-server deployment pattern", como cita o texto da Tigera. Quando seu cliente mantém registrations com uma dúzia de authorization servers ao mesmo tempo, atacante não precisa quebrar criptografia. Precisa fazer seu cliente atribuir resposta ao servidor errado.

A forma é esta. O host do seu agent está no meio de flow com servidor honesto A quando chega response que veio do servidor B controlado pelo atacante. Sem verificar issuer, cliente pode concluir exchange contra B, vazando authorization code, ou aceitar tokens emitidos por B e apresentá-los depois. RFC 9207, correção de 2021 para OAuth clássico, adicionou parâmetro explícito iss às authorization responses para cliente rejeitar qualquer coisa de issuer inesperado, e SEP-2468 traz esse requisito ao MCP. SEP-2352 lida com metade mais silenciosa: credentials. Antes, cliente podia manter client ID emitido pelo issuer A e, quando resource migrava para issuer B, apresentar credential de A a B. Às vezes funcionava, e "às vezes funciona" não é propriedade desejável em sistema auth. Então 2352 exige registrations mantidas por authorization server, vinculadas ao valor issuer, e novo registro na migração.

Também não é a primeira rodada nessa classe. A revisão de especificação 2025-06-18 tornou Resource Indicators RFC 8707 obrigatórios para tokens serem emitidos a um servidor específico, e a especificação de autorização MCP já proíbe aceitar tokens destinados a outros resources ou passá-los downstream. O pacote 2026-07-28 continua mesma trajetória: menos confiança por padrão, mais binding explícito. Se você leu meu texto MCP versus API, este é o custo da flexibilidade descrita: runtime discovery torna MCP componível e também cria essas perguntas de identidade.

A topologia um-cliente-muitos-servidores do MCP é exatamente o deployment pattern que mix-up attacks atacam: atacante não quebra crypto, faz cliente atribuir response ou credential ao authorization server errado. SEP-2468 vincula responses aos issuers via parâmetro iss do RFC 9207; SEP-2352 vincula credentials registradas ao servidor emissor, segundo a análise da Tigera e RFC 9207.

A especificação está alcançando falhas de produção

Se isso parece abstrato, não é. A string issuer vem falhando em deployments MCP reais durante todo o verão, e clientes estritos já estão tropeçando.

Em julho, usuários do cliente opencode descobriram OAuth para o servidor MCP Rovo da Atlassian falhando em discovery. Protected-resource metadata anunciava corretamente authorization server específico por tenant, mas o documento servido ali declarava issuer compartilhado simples https://auth.atlassian.com em vez do path tenant do qual foi recuperado. RFC 8414 seção 3.3 diz que valor issuer deve igualar exatamente URL usada para recuperar metadata, menos sufixo .well-known, então validação estrita do opencode rejeitou corretamente e login foi totalmente bloqueado: bug de conformidade lado Atlassian, confirmado contra endpoints live. O endpoint MCP do Context7 teve bug irmão em junho, onde authorization server anunciado e metadata issuer em subdomínio Clerk não concordavam, e SDK Go oficial MCP recusou flow. Metadata do Home Assistant omitia completamente campo issuer, quebrando clientes MCP de outro jeito.

Nenhum dos três foi exploit mix-up; foram falhas de interoperabilidade. Mas esse é o ponto. Mesma comparação de string que bloqueia servidor falso do atacante também bloqueia real mal configurado, então ecossistema está prestes a ficar bem menos tolerante com metadata sempre errada que antes passava. Texto da WorkOS sobre mix-up attacks coloca ponto operacional bem: muitas libraries OAuth ainda deixam verificação RFC 9207 desligada por padrão e aponta CVE-2026-59208 como caso onde restringir account lookups ao issuer confirmado, em vez de combinar claim sub globalmente, teria parado bug. Eu trataria referência CVE como reportada pela WorkOS, não independentemente verificada, mas princípio defensivo é prática padrão de qualquer modo.

Deployments MCP reais falharam issuer validation todo verão: servidor MCP Rovo da Atlassian serve metadata cujo issuer não corresponde à URL tenant de onde foi obtida (opencode issue #39332), endpoint Context7 anunciou um authorization server enquanto metadata declarou outro (Context7 issue #2723), e Home Assistant omitiu completamente campo issuer. RFC 8414 seção 3.3 exige valor issuer exatamente igual à retrieval URL, então clientes estritos rejeitaram corretamente os três.

O que implementadores devem fazer

Se mantém um cliente MCP:

1. Valide iss em toda authorization response agora. Rejeite mismatches com issuer em cujo flow você está e, se servidor anuncia suporte RFC 9207 mas omite parâmetro, rejeite também. Especificação é explícita que rejeitar iss ausente virá em versão futura, então trate como obrigatório hoje.

2. Particione estado de registration por authorization server. Cada client ID, secret e refresh token fica armazenado contra valor issuer que emitiu. Se protected-resource metadata de resource começar apontar a novo authorization server, registre novamente; nunca repita credential antiga.

3. Declare application_type durante Dynamic Client Registration. SEP-837 resolve classe de falha onde cliente desktop ou CLI recebe default web e é rejeitado por redirect URI localhost. Um campo, classe real de bug eliminada.

4. Restrinja account lookups ao issuer. Claim sub só deve combinar contas dentro namespace do issuer realmente validado. Nunca combine globalmente.

Se roda servidor MCP ou authorization server à frente de um: sirva metadata cujo issuer seja exatamente igual à URL de onde é obtido, incluindo tenant path, implemente protected-resource metadata por RFC 9728 e continue validando que tokens foram emitidos especificamente para seu resource. E se você está self-hosting agents contra lista crescente de servidores MCP, matemática de fleet importa: N agents vezes M servers significa N vezes M registrations vinculadas a issuer. Com dez agents é spreadsheet; com cem é registry, e especificação não opina sobre registries. Essa parte é da sua plataforma.

Implementadores devem validar iss em authorization responses, rejeitando mismatches e, quando suportado, omissões, armazenar credentials particionadas por issuer e registrar novamente na migração, declarar application_type durante Dynamic Client Registration e restringir account lookups ao issuer validado, segundo análise SEP da Tigera e orientação mix-up da WorkOS. SDKs Tier 1 devem entregar suporte dentro da janela de validação de dez semanas da especificação.

O que a especificação ainda não responde

Leia pacote de novo e note que todas seis SEPs têm em comum: endurecem exchange entre cliente OAuth e authorization server. Precisava ser feito. Mas como análise da Tigera diz claramente, token autentica cliente, não agent. Duzentos agents atrás de um host compartilham uma client identity; issuer binding nada diz sobre qual agent, em nome de quem, decidindo com base em quê, está atrás do cliente. Scopes são admissão, não policy por request. Delegation chains, agent chama agent chama server, podem ser OAuth-clean em cada hop e sem accountability end-to-end. E nada no pacote exige que alguém registre tudo isso, que é decisão correta de scope para protocolo e resposta incompleta para enterprise.

Não digo para diminuir trabalho. MCP sem issuer validation era HTTP sem certificate checking, e esse buraco está fechando. Mas quatro lacunas, agent identity, per-request authorization, delegation provenance e audit, são camada de governance e não chegam esperando especificação. São mesmas lacunas que trabalho com clientes em agent governance, e são enforced pelo environment ao redor do agent ou por ninguém.

FAQ

Qual é o problema de OAuth issuer binding no MCP?

Clientes MCP falam com muitos authorization servers descobertos em runtime, deixando-os vulneráveis a mix-up attacks: response ou credential atribuída ao servidor errado. A especificação 2026-07-28 corrige exigindo validar parâmetro iss em authorization responses, SEP-2468 adotando RFC 9207, e vincular toda credential registrada ao issuer, SEP-2352.

É vulnerabilidade no próprio MCP?

É classe de vulnerabilidade que deployment pattern do protocolo tornou prevalente, agora fechada no nível da especificação. Falhas vistas em produção neste verão, Atlassian, Context7 e Home Assistant servindo issuer-mismatched metadata, eram bugs de implementação, mas mostram quão frágil era modelo sem validação. Validação estrita agora é baseline.

Quais flows são afetados?

Authorization-code flows com qualquer cliente registrado em mais de um authorization server, Dynamic Client Registration entre servidores, uso de credentials depois que resource migra entre authorization servers e metadata discovery via documentos .well-known. Deployments single-server nunca foram risco; risco é topologia multi-server criada pelos agents.

Quando isso vira obrigatório?

A especificação 2026-07-28 é final, suporte SDK está chegando em janela de validação de dez semanas a partir do release-candidate lock de maio, e especificação é explícita que rejeitar responses sem iss será esperado em versão futura. Trate como obrigatório em tudo que construir agora.

Em resumo

Segurança OAuth é em grande parte comparação entediante de strings com consequências, e MCP acabou de encarar esse fato. O pacote 2026-07-28 importa correção OAuth de cinco anos para protocolo cuja forma um-cliente-muitos-servidores a tornou urgente, exatamente quando deployments reais começaram a falhar essa verificação em production. Atualize SDKs, valide iss, vincule registrations. Depois faça a pergunta que especificação corretamente não respondeu: quando token emitido por você é usado para tool call que nunca aprovaria, apresentado por agent que você não consegue nomear, quem detecta e onde fica registro? Essa resposta não vem de especificação. Vem do harness que você constrói ao redor.

Se está organizando auth e identity para deployment MCP, é conversa que tenho regularmente com clientes. Entre em contato.

Fontes

• 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)