MCP formaliza OAuth 2.1 como protocolo de autorização para servidores expostos via HTTP

O que a especificação trata como obrigatório

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 versão datada de 18 de junho de 2025, detalha um fluxo de autorização para servidores MCP que rodam sobre transporte HTTP. A autorização em si continua OPTIONAL: um servidor MCP pode escolher não exigir nenhum controle de acesso. Mas quando ela existe, a spec deixa de tratar o assunto como escolha de implementação e passa a exigir conformidade com um conjunto específico de RFCs.

Isso muda o cenário para quem já colocou um servidor MCP em produção com autenticação própria, tipo um header customizado ou uma chave fixa. A spec cita quatro padrões como base: OAuth 2.1 (draft IETF), OAuth 2.0 Authorization Server Metadata (RFC 8414), OAuth 2.0 Dynamic Client Registration (RFC 7591) e OAuth 2.0 Protected Resource Metadata (RFC 9728). Servidor MCP que usa HTTP MUST implementar RFC 9728; cliente MCP MUST usar essa metadata para descobrir o authorization server.

Vale notar o recorte por transporte: servidores que rodam em STDIO (o caso típico de ferramenta local chamada por um agente no próprio desktop) SHOULD NOT seguir este fluxo, e devem pegar credenciais direto do ambiente. O problema que a spec resolve é especificamente o do servidor remoto, acessível por HTTP, que qualquer cliente pode tentar chamar.

O fluxo de descoberta na prática

O primeiro contato entre cliente e servidor segue um roteiro fixo. Quando o cliente bate numa rota protegida sem token, o servidor responde 401 com um header WWW-Authenticate apontando para a URL de metadata do resource server, conforme RFC 9728 Section 5.1. O cliente MUST saber parsear esse header.

A partir daí, o cliente busca o documento de Protected Resource Metadata, que contém o campo authorization_servers com pelo menos uma entrade de authorization server. Em seguida, ele consulta a OAuth 2.0 Authorization Server Metadata (RFC 8414) desse servidor para descobrir os endpoints de autorização e token. Se o authorization server suporta Dynamic Client Registration (RFC 7591), o cliente pode se registrar sozinho, sem exigir que o usuário crie um client ID manualmente antes de usar a ferramenta.

Um exemplo mínimo de servidor Express respondendo ao desafio de autorização:

app.use('/mcp', (req, res, next) => {
 const auth = req.headers['authorization'];
 if (!auth?.startsWith('Bearer ')) {
 res.set(
 'WWW-Authenticate',
 'Bearer resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource"'
 );
 return res.status(401).json({ error: 'missing_token' });
 }
 next();
});

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

Esse par de rotas já cobre a parte de descoberta. O trabalho pesado fica na validação do token, descrita a seguir.

Validando o token: o ponto onde a maioria erra

A spec é direta sobre o que um servidor MUST fazer ao receber um token: validar que ele foi emitido especificamente para aquele servidor, checando a audiência (claim aud), conforme RFC 8707 Section 2. Não basta o token ser válido em algum lugar; ele precisa ter sido emitido PARA aquele MCP server específico.

O mecanismo que garante isso é o parâmetro resource, definido pelos Resource Indicators for OAuth 2.0 (RFC 8707). O cliente MUST incluir esse parâmetro tanto na requisição de autorização quanto na de token, identificando a URI canônica do servidor MCP de destino:

&resource=https%3A%2F%2Fmcp.example.com

Na validação do lado do servidor, isso vira uma checagem simples de claim antes de processar qualquer chamada:

function validateToken(decoded) {
 const expectedAudience = 'https://mcp.example.com/mcp';
 if (!decoded.aud?.includes(expectedAudience)) {
 throw new Error('token not issued for this resource');
 }
 return decoded;
}

Ignorar essa checagem é o erro mais perigoso que a spec tenta prevenir. Um servidor que aceita qualquer token válido, sem checar a audiência, vira alvo do que o documento chama de confused deputy problem: um atacante reusa um token legítimo, emitido para outro serviço, e o servidor MCP processa a chamada como se fosse autêntica.

Token passthrough: a prática que a spec proíbe explicitamente

Há um padrão comum em protótipos de servidor MCP que a especificação trata como proibido: repassar o token recebido do cliente, sem modificação, para uma API upstream. A spec é taxativa:

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

MCP servers MUST NOT accept or transit any other tokens.Especificação do Model Context Protocol, seção Authorization

Se o servidor MCP precisa chamar uma API upstream em nome do usuário, ele deve atuar como cliente OAuth dessa API, com um token próprio emitido pelo authorization server upstream. Esse token upstream é uma credencial separada, gerada numa troca independente, não o mesmo bearer token que o cliente MCP enviou.

Na prática, isso significa que um servidor MCP que hoje simplesmente encaminha o Authorization header recebido para a API de terceiros (por exemplo, um proxy fino sobre a API do GitHub ou do Google) está violando a regra, mesmo que funcione. A correção exige implementar um segundo fluxo OAuth, completo, entre o servidor MCP e o provedor upstream.

PKCE e os outros requisitos de segurança que viram checklist

Além da validação de audiência, a spec lista um conjunto de exigências que funcionam como checklist de revisão para quem está corrigindo um servidor existente:

• PKCE é obrigatório no cliente para toda troca de código de autorização, prevenindo interceptação do código;
• todo endpoint de authorization server deve ser servido via HTTPS, e redirect URIs só podem ser localhost ou HTTPS;
• redirect URIs devem estar pré-registradas, e o authorization server MUST validar correspondência exata, não prefixo;
• tokens de acesso NUNCA vão na query string da URL, só no header Authorization: Bearer;
• tokens inválidos ou expirados retornam sempre 401; falta de escopo ou permissão retorna 403.

Nenhum desses pontos é novo para quem já trabalhou com OAuth 2.1 em outro contexto. A diferença é que a spec do MCP os amarra especificamente ao caso de um agente de IA chamando ferramentas remotas, onde o custo de um token vazado é maior: ele não abre acesso a uma página, abre acesso a uma ferramenta que o agente pode invocar de forma autônoma.

Quando não vale a pena implementar o fluxo inteiro

Servidor MCP que roda só em STDIO, consumido localmente por um cliente desktop no mesmo processo ou máquina do usuário, está fora do escopo deste fluxo por definição da própria spec: ele deve pegar credenciais do ambiente, não montar um authorization server. Implementar Protected Resource Metadata e Dynamic Client Registration nesse caso é trabalho sem retorno.

O fluxo completo também é exagero para um servidor MCP interno, usado só por processos confiáveis dentro de uma rede fechada, sem exposição pública. Nesse cenário, um esquema de autenticação mais simples (mTLS, token de serviço com rotação curta) resolve com menos superfície de ataque do que montar um authorization server OAuth 2.1 completo só para cumprir a letra da especificação.

Fora desses dois casos, qualquer servidor MCP acessível por HTTP e exposto além da rede local é candidato direto à correção: a especificação oficial do Model Context Protocol já descreve o roteiro de ponta a ponta, e os RFCs que ela referencia (8414, 7591, 9728, 8707) já têm implementações maduras em bibliotecas de OAuth para praticamente todas as linguagens usadas em backend↳Back-end49 conteúdosIntegração front-end com backend: 7 decisões que evitam caos entre APIs, BFF e GraphQLDev (Back & Front) · abr 2026Como criar uma FAKE API REST para testes — JSONPlaceholderDev (Back & Front) · set 2025Construindo um aplicativo de bate-papo de IA simples com Spring AI e AngularDev (Back & Front) · jul 2025Ver tudo em Dev (Back & Front) → hoje.

Fonte: Especificação oficial do Model Context Protocol — seção Authorization