MCP SEP-2468: Parâmetro Iss para Defesa contra Mistura de OAuth

O que: MCP SEP-2468 alinha o fluxo de autorização do MCP com RFC 9207: os servidores de autorização podem anunciar suporte ao iss e incluir o parâmetro iss em suas respostas; os clientes são obrigados a validar que iss byte a byte em relação ao emissor que haviam registrado originalmente para o fluxo.

Por que: Um host MCP frequentemente confia em mais de um provedor de identidade — SSO corporativo, além de um IdP parceiro e um IdP de desenvolvedor para testes locais — e sem um sinal nomeando o AS, um atacante que controla (ou possui um registro válido em) qualquer IdP confiável pode misturar códigos de autorização entre servidores e enganar o cliente para gastar um código de atacante em um endpoint de token legítimo.

vs anterior: O fluxo anterior não tinha campo de emissor na resposta de autorização, então os clientes tinham que adivinhar a partir do estado da sessão — a lacuna estrutural que a família de ataques de mistura OAuth explora, e a única capacidade que o escopo não pode fechar porque o atacante está abusando da incerteza do cliente sobre qual AS respondeu, não abusando de um escopo.

Pense nisso como

Um porteiro que compara seu carimbo de pulso com a lista de convidados.

                       RESPOSTA DE AUTORIZAÇÃO
                            │
              ┌─────────────┴─────────────┐
              │                           │
      ┌───────▼────────┐         ┌────────▼───────┐
      │   carimbo: A   │         │   carimbo: B   │
      │ (registrado: A)│         │ (registrado: A)│
      └───────┬────────┘         └────────┬───────┘
              │                           │
       string-equal OK             string-equal FAIL
       para emissor registrado        para emissor registrado
              │                           │
              ▼                           ▼
        ✓ prosseguir para            ✗ rejeitar resposta
          troca de token              mistura bloqueada

• cliente MCP = o porteiro na porta
• emissor registrado = o único nome de local na lista de convidados
• resposta de autorização = um convidado chegando
• parâmetro iss = o nome do local impresso no carimbo de pulso do convidado
• verificação de string igual = o porteiro lendo o carimbo letra por letra
• ataque de mistura OAuth = alguém chegando com um carimbo do bar ao lado

Glossário rápido

MCP — O Protocolo de Contexto do Modelo — um protocolo aberto para conectar hosts de LLM a servidores de ferramentas externas. O host executa o modelo e o loop do agente; os servidores expõem ferramentas, recursos e prompts via JSON-RPC. A autorização entre hosts e servidores está cada vez mais padronizada no OAuth 2.0, que é o que o SEP-2468 fortalece.

SEP — Proposta de Melhoria de Especificação — o documento de mudança estilo RFC do MCP. O SEP-2468 é a proposta que traz o parâmetro iss da RFC 9207 para a autorização do MCP. Propostas complementares incluem SEP-2663 (manipuladores de tarefas assíncronas) e SEP-2577 (depreciações de recursos).

AS (Servidor de Autorização) — O papel do OAuth que autentica o usuário e emite o código de autorização e o token de acesso. No MCP, seu SSO corporativo, um provedor de identidade parceiro e um IdP local de desenvolvedor podem ser todos ASes em que o cliente confia ao mesmo tempo.

parâmetro iss (RFC 9207) — Uma string de URL que o AS inclui em suas respostas de autorização quando anuncia suporte à RFC 9207 em seus metadados, identificando qual AS produziu a resposta. Definido na RFC 9207. Os clientes são obrigados a compará-lo byte a byte (por RFC 3986 §6.2.1 comparação simples de strings) com o emissor que haviam registrado quando iniciaram o fluxo; quando um AS não anuncia suporte ao iss, os clientes podem aplicar política local.

ataque de mistura OAuth — Uma família de ataques documentada onde um cliente que confia em múltiplos ASes é enganado para enviar o código de autorização ou token de um AS para um AS diferente. O resultado é que o cliente acredita que está se comunicando com um IdP enquanto, na verdade, autenticou-se em outro — uma confusão de privilégios que o restante da pilha do agente não tem sinal para detectar.

escopo de capacidade — O padrão de defesa de conceder às ferramentas a capacidade mínima que precisam (por exemplo, acesso a arquivos somente leitura para um resumidor). O escopo de capacidade é uma defesa complementar — limita o raio de explosão de qualquer ferramenta comprometida, mas NÃO informa qual AS emitiu uma determinada resposta de autorização.

defesa estrutural — Uma defesa que remove uma confusão na camada de protocolo em vez de depender de política. O parâmetro iss é estrutural: o cliente não pode acidentalmente validar contra o emissor errado porque a resposta em si nomeia o AS que a produziu.

A notícia. Em 17 de maio de 2026, MCP SEP-2468 foi mesclado na especificação do Protocolo de Contexto do Modelo — proposto em 25 de março, aceito em 5 de maio. A mudança recomenda que os servidores de autorização anunciem suporte ao iss em seus metadados e incluam o parâmetro em suas respostas de autorização, e exige que os clientes o validem em relação ao emissor registrado usando comparação simples de strings conforme RFC 3986 §6.2.1. A motivação, retirada diretamente da RFC 9207, é fechar o ataque de mistura OAuth de longa data em clientes que confiam em múltiplos provedores de identidade.

Imagine o porteiro. Ele tem um nome na sua lista de convidados — digamos, idp-a.example — e esta noite esse é o único local cujos convidados ele está deixando entrar. Um convidado se aproxima. Sem um carimbo de pulso, o porteiro não tem como saber de qual lista de local essa pessoa veio. Talvez realmente seja o local certo. Talvez seja alguém do bar ao lado que espera que você não verifique. O porteiro tem que adivinhar. Esse é o cenário de mistura OAuth antes do SEP-2468: o cliente inicia um fluxo de autorização com um AS, uma resposta de autorização volta, e o único sinal que o cliente tem é seu próprio estado de sessão — que o atacante está tentando confundir ativamente.

O caminho rápido é que cada convidado recebe um carimbo, impresso com o nome do local. O porteiro não precisa lembrar rostos. Ele lê o carimbo, compara letra por letra com o nome em sua lista, e decide na hora. O carimbo é o parâmetro iss. Não é o token. É metadados sobre qual AS produziu a resposta. O cliente compara response.iss com o emissor que havia registrado quando iniciou o fluxo, letra por letra. Correspondência → continue para a troca de token. Desvio → rejeitar a resposta, não importa quão convincente o restante da carga útil pareça.

A pegadinha — e isso é o que torna a defesa estrutural carregadora — é que o escopo de capacidade e outras verificações de camada de conteúdo não podem substituir a verificação do emissor. Suponha que todas as ferramentas em seu agente sejam somente leitura e todos os escopos sejam mínimos. Um atacante ainda vence a mistura se o cliente pegar um código de autorização emitido por idp-b.evil e trocá-lo no endpoint de token de idp-a.example, porque o eventual token de acesso será para o IdP legítimo — cunhado da sessão do usuário errado. Os dados comprometidos não fluem através dos parâmetros de uma ferramenta; eles fluem através da confusão do cliente sobre qual IdP autenticou o usuário. Essa é uma camada acima da superfície de ataque da ferramenta que as demais proteções do agente foram construídas para policiar, que é exatamente por isso que o módulo de Guardrails em Camadas sequencia defesas estruturais antes da política.