MCP oficializou autorização via OAuth 2.1 em 2025: o checklist para servidores sem autenticação

Por que isso importa agora, mesmo sendo de 2025

A especificação de Authorization 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 → foi publicada na revisão de 18 de junho de 2025 do protocolo e está disponível em modelcontextprotocol.io. Ela define, pela primeira vez de forma completa, como um servidor MCP exposto via HTTP deve se comportar como um resource server OAuth 2.1: validar tokens, descobrir o authorization server e recusar requisições sem credencial válida.

O problema é que boa parte dos servidores MCP em produção foi construída durante a corrida de agentes de 2024 e 2025, sem essa camada. A própria spec deixa claro que autorização é OPTIONAL para implementações MCP, mas quem decide usar transporte HTTP (ao contrário de STDIO, que pega credenciais do ambiente) SHOULD seguir a especificação à risca. Isso significa que todo servidor HTTP sem auth não está quebrando uma regra obrigatória, mas está fora do caminho recomendado, e isso cobra preço no momento em que um cliente mais rigoroso aparece do outro lado.

O que a spec realmente define

O desenho tem três papéis: o MCP server atua como resource server OAuth 2.1, o MCP client faz requisições em nome do usuário (resource owner), e o authorization server fica responsável por autenticar a pessoa e emitir o token. A spec não exige que o authorization server seja o próprio MCP server: pode ser um serviço separado, como Auth0, Okta ou um Keycloak interno.

Quatro padrões formam a base técnica exigida:

• OAuth 2.1 (draft-ietf-oauth-v2-1-13), com medidas de segurança para clients confidenciais e públicos;
• OAuth 2.0 Protected Resource Metadata (RFC9728), que o MCP server MUST implementar;
• OAuth 2.0 Authorization Server Metadata (RFC8414), que o authorization server MUST fornecer;
• OAuth 2.0 Dynamic Client Registration (RFC7591), que authorization server e client SHOULD suportar.

Protected Resource Metadata: como o servidor se anuncia

Na prática, isso significa que todo MCP server HTTP precisa expor um documento de metadata descrevendo onde está o authorization server responsável por ele. Quando o servidor recebe uma requisição sem token válido, ele MUST responder com 401 Unauthorized e incluir o cabeçalho WWW-Authenticate apontando para a URL dessa metadata, conforme a RFC9728 Section 5.1:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource"

O documento retornado nessa URL precisa trazer o campo authorization_servers com pelo menos um authorization server válido. É esse campo que o cliente MCP usa para descobrir onde mandar o usuário para autenticar, seguindo depois a RFC8414 para obter os endpoints do authorization server (token endpoint, authorization endpoint, etc.).

PKCE e o resource parameter: amarrando o token ao servidor certo

Dois mecanismos do OAuth 2.1 ganham peso extra dentro do MCP. O primeiro é PKCE: todo MCP client MUST implementá-lo conforme OAuth 2.1 Section 7.5.2, porque sem isso um authorization code interceptado pode ser trocado por um token por qualquer um que o capture. O segundo é o resource parameter da RFC 8707: o client 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.

A própria spec lista exemplos. São URIs canônicas válidas https://mcp.example.com/mcp, https://mcp.example.com:8443 e https://mcp.example.com/server/mcp. Já mcp.example.com (sem esquema) e https://mcp.example.com#fragment (com fragmento) são inválidas. Um pedido de autorização típico leva o parâmetro assim: &resource=https%3A%2F%2Fmcp.example.com.

Esse amarramento existe para impedir que um token emitido para um serviço seja reaproveitado em outro. No lado do servidor, a contrapartida é obrigatória: o MCP server MUST validar que o token recebido foi emitido especificamente para ele como audience, segundo RFC 8707 Section 2. Token que não traz essa audience correta tem que ser rejeitado com 401.

Dynamic Client Registration: evita atrito, mas é opcional

Diferente dos itens acima, o RFC7591 entra como SHOULD, não MUST. A ideia é que o client MCP não precise saber de antemão todos os servidores possíveis e seus authorization servers: ele se registra dinamicamente e recebe um client_id sem intervenção manual. Isso reduz fricção, especialmente para quem constrói um cliente genérico que conecta a múltiplos servidores MCP de terceiros.

Se o authorization server não suporta registro dinâmico, a spec prevê duas saídas: ou o client embute um client_id fixo (e credenciais, se aplicável) específico para aquele authorization server, ou apresenta uma UI para o usuário inserir esses dados depois de registrar o OAuth client manualmente. Para quem opera um servidor MCP interno, com um número pequeno e conhecido de clients, pular o registro dinâmico costuma ser aceitável; o custo aparece quando o servidor precisa ser acessado por clients variados e desconhecidos.

O erro que vira vulnerabilidade: token passthrough

A parte mais sensível da spec, e a mais fácil de errar sob pressão de prazo, é a seção sobre confused deputy e token passthrough. Se o servidor MCP atua como proxy para uma API upstream, ele MUST NOT repassar adiante o token que recebeu do client MCP sem modificação. O token usado na API upstream precisa ser outro, emitido pelo authorization server dessa API.

A razão é direta:

Um atacante pode explorar servidores MCP atuando como intermediários para APIs de terceiros, levando a vulnerabilidades de confused deputy. Usando authorization codes roubados, eles conseguem obter tokens de acesso sem consentimento do usuário.

Model Context Protocol, especificação oficial (revisão 2025-06-18)Attackers can exploit MCP servers acting as intermediaries to third-party APIs, leading to confused deputy vulnerabilities. By using stolen authorization codes, they can obtain access tokens without user consent.

Servidores MCP que fazem proxy com client_id estático também MUST obter consentimento do usuário para cada client registrado dinamicamente, antes de encaminhar a requisição ao authorization server de terceiros, mesmo que esse authorization server já peça consentimento adicional por conta própria.

Checklist para quem já tem servidor MCP em produção

Para quem subiu um servidor MCP via HTTP sem nenhuma dessas camadas, o caminho de conformidade passa por sete pontos concretos:

1. Confirmar o transporte: se é STDIO puro, a spec recomenda não seguir esse fluxo e usar credenciais do ambiente; se é HTTP, a conformidade se aplica.
2. Publicar um endpoint de Protected Resource Metadata (RFC9728) com o campo authorization_servers preenchido.
3. Responder 401 com WWW-Authenticate apontando para essa metadata sempre que faltar token válido.
4. Validar a audience de todo token recebido, rejeitando qualquer um que não tenha sido emitido especificamente para aquele servidor.
5. Garantir que o servidor nunca encaminha o token do client MCP para uma API upstream sem trocá-lo por um token próprio daquela API.
6. Se o servidor também implementa um client MCP, garantir suporte a PKCE e ao parâmetro resource em toda requisição de autorização e de token.
7. Avaliar se vale suportar Dynamic Client Registration (RFC7591) ou se um client_id fixo resolve, dado o número de clients que acessam o servidor.

Os códigos de erro que a spec exige para cada situação seguem um padrão simples:

Onde não vale a pena implementar tudo

Servidor MCP que roda só localmente via STDIO, consumido por um único client confiável na mesma máquina, não precisa de nada disso: a própria spec recomenda não seguir esse fluxo nesse caso e pegar credenciais do ambiente (uma variável como MCP_API_KEY, por exemplo). O custo de implementar Protected Resource Metadata, descoberta de authorization server e PKEC só se paga quando o servidor é exposto pela rede e acessado por clients que você não controla totalmente.

Para quem está nesse meio-termo, com um servidor HTTP interno e poucos clients conhecidos, a aposta mais barata costuma ser pular Dynamic Client Registration e token audience fina a princípio, mas implementar a Protected Resource Metadata e a validação de audience desde já. São os dois pontos que, segundo a própria spec, sustentam a diferença entre um servidor MCP em conformidade e um aberto a reuso indevido de token.

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