MCP exige OAuth 2.1 para servidores remotos desde junho de 2025: veja o que muda no código

O que a especificação exige, e desde quando

A seção Authorization da especificação 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 →, na revisão de 18 de junho de 2025, formaliza um papel que antes era implícito: todo servidor MCP exposto via transporte HTTP que queira oferecer autorização passa a atuar como um resource server OAuth 2.1. O documento é claro sobre o escopo: autorização continua sendo opcional para implementações MCP, mas quem a implementa deve seguir esse desenho, não inventar o próprio esquema.

Vale separar dois mundos. Servidores que rodam sobre STDIO (o caso típico de uma ferramenta MCP local, chamada por um processo filho) não devem seguir essa especificação: a orientação da própria spec é que eles peguem credenciais do ambiente, como sempre fizeram. O impacto recai sobre quem expõe um servidor MCP remoto, acessível por HTTP, para múltiplos clientes que não controla.

Do token estático ao resource server

O padrão mais comum até aqui, em protótipos e em produtos internos, era um bearer token fixo guardado em uma variável de ambiente e comparado byte a byte. Em código, isso costuma parecer com:

app.use((req, res, next) => {
  const token = req.headers.authorization?.replace('Bearer ', '');
  if (token !== process.env.MCP_STATIC_TOKEN) {
    return res.status(401).send('Unauthorized');
  }
  next();
});

Esse código passa a ser insuficiente em dois pontos centrais da spec: o servidor não anuncia onde fica o authorization server (exigência do RFC9728, Protected Resource Metadata) e não valida para quem aquele token foi emitido (exigência de audience binding do RFC8707). Um token estático não carrega audience nenhuma para validar, então ele simplesmente não existe nesse modelo.

O que o servidor remoto precisa passar a implementar

A migração tem peças específicas, e a spec marca a maioria como obrigatória (MUST), não como recomendação:

• Um endpoint de Protected Resource Metadata (RFC9728), que diz ao cliente onde está o authorization server.
• O cabeçalho WWW-Authenticate em toda resposta 401, apontando para esse endpoint de metadata.
• Validação de que o token recebido tem audience igual à URI canônica do próprio servidor (RFC8707).
• Suporte, do lado do authorization server, a Dynamic Client Registration (RFC7591) e a Authorization Server Metadata (RFC8414) — para que clientes novos não precisem de client ID hardcoded.
• Do lado do cliente, uso obrigatório de PKCE no fluxo de código de autorização.

Um esqueleto de migração no servidor fica assim:

// Endpoint exigido pelo RFC9728
app.get('/.well-known/oauth-protected-resource', (req, res) => {
  res.json({
    resource: 'https://mcp.example.com/mcp',
    authorization_servers: ['https://auth.example.com']
  });
});

app.use((req, res, next) => {
  const token = req.headers.authorization?.replace('Bearer ', '');
  if (!token) {
    res.set('WWW-Authenticate',
      'Bearer resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource"');
    return res.status(401).send();
  }
  const claims = verifyJwt(token, {
    audience: 'https://mcp.example.com/mcp',
    issuer: 'https://auth.example.com'
  });
  if (!claims) return res.status(401).send();
  req.user = claims;
  next();
});

O ponto que mais costuma pegar quem vem do modelo antigo: validar audience não é opcional nem cosmético. Sem isso, um token emitido para um serviço totalmente diferente, mas pelo mesmo authorization server, seria aceito pelo servidor MCP como se fosse válido ali.

O problema do "confused deputy" e por que repassar token é proibido

A spec dedica uma seção inteira ao caso de servidor MCP que atua como proxy para uma API de terceiros. Se esse servidor aceitar o token do cliente e simplesmente repassá-lo para a API upstream sem revalidar, ele vira um alvo clássico de confused deputy: um atacante com um token roubado consegue fazer a API downstream confiar nele como se tivesse vindo legitimamente do servidor MCP.

Servidores MCP não devem aceitar nem repassar nenhum outro token.

MCP servers MUST NOT accept or transit any other tokens.Especificação do Model Context Protocol, seção Authorization (revisão 2025-06-18)

Na prática, isso significa que, quando o servidor MCP precisa chamar uma API upstream em nome do usuário, ele deve agir como cliente OAuth dessa API e obter um token próprio, separado do token que recebeu do cliente MCP. É mais código e mais uma relação de confiança para gerenciar, não um simples repasse de header.

Quando essa migração não compensa

Nem todo servidor MCP precisa disso amanhã. A própria spec trata autorização como capacidade opcional, e a recomendação de não seguir o fluxo se aplica integralmente a servidores STDIO, que continuam pegando credenciais do ambiente local. Ferramentas internas, rodando atrás de uma VPN corporativa e chamadas só por um cliente que a própria equipe controla, também têm um caso razoável para adiar: o ganho de segurança do fluxo completo OAuth 2.1 compensa menos quando já existe uma camada de rede fechando o acesso.

O cenário em que a migração deixa de ser opcional, na prática, é o servidor remoto, multi-tenant, pensado para ser descoberto e usado por clientes MCP de terceiros. Nesse caso, um cliente compatível com a spec vai esperar exatamente o fluxo descrito: metadata de recurso protegido, descoberta do authorization server, PKCE e tokens com audience correta. Sem isso, a conexão simplesmente não se completa do jeito que o protocolo prevê.

Fonte: Especificação oficial do Model Context Protocol — seção Authorization (revisão 2025-06-18)