Servidores MCP em produção precisam migrar para OAuth Resource Servers desde a spec de junho de 2025

A revisão 2025-06-18 do Model Context Protocol↳MCP7 conteúdosArquitetura de Sistemas Cognitivos: Integração de RAG, MCP e LLMs no Ecossistema .NETDev (Back & Front) · abr 2026MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025Agentes de IA com LLMs de Código Aberto: Integração Prática com o Model Context Protocol (MCP)AI · ago 2025Ver tudo em AI → transformou todo servidor MCP num OAuth Resource Server. Quem ainda usa API key estática corre risco de ficar incompatível com clients MCP que já seguem essa revisão da especificação.

Se o servidor MCP (Model Context Protocol) da sua empresa ainda autentica clients com uma chave fixa num header customizado, ele está rodando contra uma versão da especificação que já foi substituída há mais de um ano. O changelog oficial do protocolo, publicado para a revisão 2025-06-18, formalizou um modelo de autorização que classifica servidores MCP como OAuth Resource Servers e muda a forma como clients MCP e agentes compatíveis com a especificação negociam acesso a um servidor MCP.

Quem subiu um servidor MCP em 2024 ou no início de 2025, antes dessa revisão, provavelmente implementou autenticação por conta própria: token estático, API key no header Authorization, ou nem isso. A revisão de junho de 2025 formalizou um modelo de autorização específico, e isso tem implicações concretas para quem já tem serviço no ar.

O que o changelog mudou, na prática

O documento da fonte lista a mudança como a terceira da seção de "major changes": classificar servidores MCP como OAuth Resource Servers, com metadados de recurso protegido para apontar o Authorization Server correspondente.

Classificar servidores MCP como Servidores de Recursos OAuth, adicionando metadados de recurso protegido para descobrir o servidor de autorização correspondente.

Classify MCP servers as OAuth Resource Servers, adding protected resource metadata to discover the corresponding Authorization server.Model Context Protocol, especificação 2025-06-18

Na prática, isso significa que o servidor MCP deixa de ser responsável por validar credenciais sozinho. Ele delega essa função a um Authorization Server externo (pode ser Auth0, Okta, Keycloak ou um provider próprio) e só precisa anunciar onde esse servidor está.

O changelog também traz duas mudanças que pegam quem só olhou o título da migração:

• Resource Indicators obrigatórios (RFC 8707): clients MCP agora precisam declarar para qual servidor o token foi solicitado, evitando que um token emitido para um serviço seja reaproveitado em outro (o clássico ataque de "confused deputy").
• Header MCP-Protocol-Version obrigatório: toda requisição HTTP subsequente ao handshake inicial precisa declarar a versão do protocolo negociada, não só a primeira.

Por que o modelo antigo de auth vira risco

Um servidor MCP com API key fixa funciona enquanto só um client confiável o acessa. O problema aparece quando o mesmo token circula entre múltiplos agentes, integrações de terceiros ou pipelines automatizados: não há como revogar acesso de um cliente específico sem quebrar todos os outros, e não há validação de que o token foi emitido para aquele servidor.

Com Resource Indicators, o fluxo exige que o token carregue um claim de audience (aud) correspondente ao recurso solicitado. Um servidor que não valida esse claim continua vulnerável mesmo depois de "migrar" apenas trocando o transporte para HTTPS com Bearer token: o ponto da mudança é a validação, não só o formato do header.

Passo a passo para migrar um servidor MCP existente

Nota da redação: o código desta seção não foi executado em ambiente real. Valide antes de usar em produção.

1. Mapeie o fluxo de auth atual

Antes de tocar em código, identifique onde está a verificação de identidade hoje: middleware que lê um header customizado, checagem de API key num banco, ou nenhuma verificação real. Esse inventário determina quanto do fluxo pode ser preservado e quanto precisa ser substituído por um Authorization Server dedicado.

2. Exponha o Protected Resource Metadata

O servidor precisa responder num endpoint bem conhecido com os dados do Authorization Server que protege o recurso. Um exemplo mínimo de resposta:

{
  "resource": "https://mcp.suaempresa.com",
  "authorization_servers": [
    "https://auth.suaempresa.com"
  ],
  "bearer_methods_supported": ["header"]
}

É esse documento que um client MCP consulta antes de iniciar o fluxo OAuth, em vez de assumir que o próprio servidor MCP valida a senha.

3. Valide o Resource Indicator no token recebido

O ponto que mais gente pula: receber um Bearer token válido não basta, é preciso confirmar que ele foi emitido para este recurso. Um exemplo de verificação em Node.js↳Node.js45 conteúdosComo criar aplicações console em Node.jsDev (Back & Front) · fev 2025Entendendo o ciclo de publicação do Node.jsDev (Back & Front) · fev 2020Nodejs por baixo dos panosDev (Back & Front) · jul 2019Ver tudo em Dev (Back & Front) →, assumindo um JWT com claim aud:

function validarToken(payload, resourceEsperado) {
  const audiences = Array.isArray(payload.aud) ? payload.aud : [payload.aud];
  if (!audiences.includes(resourceEsperado)) {
    throw new Error('Token não emitido para este recurso');
  }
  return true;
}

Sem essa checagem, o servidor aceita um token roubado ou vazado de outra integração, mesmo que a assinatura do JWT seja válida.

4. Adicione o header de versão em toda requisição

A spec deixou de aceitar MCP-Protocol-Version só no handshake inicial. Toda requisição subsequente via HTTP precisa declarar a versão negociada. Um middleware simples resolve isso:

app.use((req, res, next) => {
  const versao = req.headers['mcp-protocol-version'];
  if (versao !== '2025-06-18') {
    return res.status(400).json({ error: 'protocol_version_mismatch' });
  }
  next();
});

5. Teste localmente antes de liberar em produção

Para validar o fluxo sem depender de infraestrutura real, suba o servidor MCP em localhost e um Authorization Server de teste (Keycloak em container, por exemplo). Aponte um client MCP de teste para o endpoint de metadata local e confirme três coisas: o client consegue descobrir o Authorization Server pelo metadata, o fluxo de autorização retorna um token com o aud correto, e o servidor rejeita tokens com audience diferente.

O que quebra se o servidor não migrar

Clients MCP que já seguem a revisão 2025-06-18 esperam encontrar o endpoint de Protected Resource Metadata antes de negociar acesso. Um servidor que não o expõe pode simplesmente falhar o handshake silenciosamente, dependendo de como o client trata a ausência desse metadata. Mais grave: um servidor que aceita qualquer Bearer token sem validar o Resource Indicator fica exposto a reaproveitamento de tokens emitidos para outros serviços, exatamente o cenário que o RFC 8707 foi desenhado para fechar.

A mudança de SHOULD para MUST na seção de Lifecycle Operation reforça esse ponto: o que antes era recomendação de boas práticas virou requisito de conformidade. Servidores que ignoram essa parte da spec não estão simplesmente "desatualizados", estão fora da especificação que os clients modernos assumem como padrão.

Quando não vale a pena migrar agora

Se o servidor MCP roda só internamente, atrás de VPN, com um único client confiável e sem exposição externa, o custo de implementar um Authorization Server completo pode não compensar no curto prazo. Nesse cenário, vale manter o monitoramento do changelog oficial e planejar a migração como parte de um ciclo de hardening de segurança, não como correção emergencial. O risco real aparece quando o servidor atende múltiplos clients ou é acessado por agentes de terceiros, caso em que a validação de audience deixa de ser opcional.

Fonte 1: Model Context Protocol — Specification Changelog (2025-06-18) (https://modelcontextprotocol.io/specification/2025-06-18/changelog)

Key Changes - Model Context Protocol

Documentation Index Fetch the complete documentation index at: /llms.txt Use this file to discover all available pages before exploring further. Skip to main content This document lists changes made to the Model Context Protocol (MCP) specification since the previous revision, 2025-03-26 .

​ Major changes

Remove support for JSON-RPC batching (PR #416 )

Add support for structured tool output (PR #371 )

Classify MCP servers as OAuth Resource Servers , adding protected resource metadata to discover the corresponding Authorization server. (PR #338 )

Require MCP clients to implement Resource Indicators as described in RFC 8707 to prevent malicious servers from obtaining access tokens. (PR #734 )

Clarify security considerations and best practices in the authorization spec and in a new security best practices page .

Add support for elicitation , enabling servers to request additional information from users during interactions. (PR #382 )

Add support for resource links in tool call results. (PR #603 )

Require negotiated protocol version to be specified via MCP-Protocol-Version header in subsequent requests when using HTTP (PR #548 ).

Change SHOULD to MUST in Lifecycle Operation

​ Other schema changes

Add _meta field to additional interface types (PR #710 ), and specify proper usage .

Add context field to CompletionRequest , providing for completion requests to include previously-resolved variables (PR #598 ).

Add title field for human-friendly display names, so that name can be used as a programmatic identifier (PR #663 )

​ Full changelog For a complete list of all changes that have been made since the last protocol revision, see GitHub . Was this page helpful? Yes No Assistant Responses are generated using AI and may contain mistakes.

Fonte: Model Context Protocol — Specification Changelog (2025-06-18)