MCP passa a exigir OAuth 2.1 em servidores HTTP: o que quebra em produção

A especificação oficial 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 →, revisada em junho de 2025, torna obrigatório um fluxo específico de OAuth 2.1 para servidores expostos via HTTP. Quem ligou agentes a Supabase, Convex ou APIs internas por atalhos mais simples precisa rever como os tokens circulam.

O que a especificação exige desde junho de 2025 (e o que continua opcional)

A especificação oficial do Model Context Protocol dedica uma seção inteira a autorização, na revisão publicada em 18 de junho de 2025. O texto deixa claro, logo no início, que suportar autorização continua sendo opcional para qualquer implementação MCP. O ponto que pega quem já tem servidor em produção vem no parágrafo seguinte: a partir do momento em que a implementação roda sobre transporte HTTP e decide suportar autorização, ela deve seguir exatamente este fluxo baseado em OAuth 2.1, e não uma versão simplificada ou caseira dele.

A mesma seção isenta explicitamente o transporte STDIO: servidores locais, invocados por um processo filho (o caso comum de quem testa um servidor MCP via npx ou uv run dentro do Claude Desktop ou de um agente próprio), não devem seguir essa especificação e, em vez disso, pegam credenciais do ambiente, como uma variável em .env. Boa parte dos protótipos que rodam só no laptop, sem porta exposta, fica de fora da mudança. O problema aparece quando o mesmo servidor sai do laptop e passa a atender múltiplos agentes por HTTP, caso típico de integração com Supabase, Convex ou uma API interna da empresa.

O descompasso que pega servidores de produção desprevenidos

Para um servidor HTTP que decide suportar autorização, a especificação amarra quatro padrões IETF numa sequência obrigatória. Um servidor MCP construído antes de junho de 2025 com um simples Authorization: Bearer <chave-fixa> dificilmente cumpre todos eles, mesmo que a autenticação em si funcione.

• RFC 9728 (Protected Resource Metadata): o servidor MCP precisa publicar um documento informando onde está o authorization server, listado no campo authorization_servers.
• RFC 8414 (Authorization Server Metadata): o authorization server precisa expor seus próprios endpoints de forma descobrível.
• RFC 7591 (Dynamic Client Registration): cliente e authorization server deveriam suportar registro automático de client_id, sem fricção manual.
• RFC 8707 (Resource Indicators): todo pedido de token precisa incluir o parâmetro resource com a URI canônica do servidor MCP, amarrando o token a esse destino específico.

Na prática, isso muda a resposta de erro que o servidor devolve. Em vez de um 401 solto, a especificação exige o header WWW-Authenticate apontando para a metadata:

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

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

Um cliente MCP escrito antes dessa revisão, que só sabia tratar 401 como "peça a chave de novo", não sabe seguir esse header nem descobrir o authorization server sozinho. Ele simplesmente para de autenticar, sem mensagem de erro clara para quem está depurando.

O padrão que a especificação proíbe: repassar o token adiante

Um atalho comum em implementações rápidas de MCP sobre Supabase ou Convex é pegar o token de sessão que o cliente já tem (o JWT emitido pelo GoTrue do Supabase, por exemplo) e simplesmente reenviá-lo, sem alterações, para a API upstream ao atender a chamada da ferramenta. Funciona em teste local e some despercebido em produção, até alguém ler a seção de segurança da especificação.

Se o servidor MCP faz requisições a APIs upstream, ele pode atuar como um cliente OAuth frente a elas. O token usado na API upstream é um token separado, emitido pelo servidor de autorização upstream. O servidor MCP não deve repassar o token que recebeu do cliente MCP.

If the MCP server makes requests to upstream APIs, it may act as an OAuth client to them. The access token used at the upstream API is a separate token, issued by the upstream authorization server. The MCP server MUST NOT pass through the token it received from the MCP client.Especificação do Model Context Protocol, revisão 2025-06-18

O motivo é o chamado "confused deputy": a API downstream (Supabase, Convex, ou o sistema interno) nunca validou que aquele token passou pelo fluxo correto do servidor MCP, e um token vazado nos logs do servidor vale tanto quanto a chave mestra. A especificação vai além e exige que servidores proxy que usam client_id estático obtenham consentimento explícito do usuário para cada cliente MCP registrado dinamicamente, antes de encaminhar qualquer coisa ao authorization server de terceiros.

Como fica o roteiro de adequação

Para quem precisa trazer um servidor HTTP existente para dentro da especificação, o caminho descrito por ela segue, em linhas gerais, esta sequência:

1. Publicar o documento de Protected Resource Metadata em /.well-known/oauth-protected-resource, com o campo authorization_servers preenchido.
2. Trocar qualquer 401 solto por um 401 com o header WWW-Authenticate apontando para essa URL de metadata.
3. Apontar para um authorization server, próprio ou de terceiros (Auth0, Clerk, WorkOS, ou o próprio provedor de auth do Supabase), que exponha metadata via RFC 8414 e, idealmente, Dynamic Client Registration via RFC 7591.
4. Exigir e validar o parâmetro resource nas requisições de token, amarrando o token à URI canônica do servidor MCP, não à API upstream.
5. Trocar o token do cliente por um token próprio antes de chamar Supabase, Convex ou a API interna, em vez de repassar o Bearer recebido sem alteração.
6. Implementar PKCE no cliente e preferir tokens de vida curta, com rotação de refresh token para clientes públicos.

Num projeto típico que já usa um provedor de identidade gerenciado, os itens 3 e 6 tendem a já estar resolvidos pela plataforma; os itens 1, 2 e 5 costumam ser o trabalho real de código no servidor MCP.

Quando a migração pode esperar

Servidores que só atendem via STDIO, dentro de uma ferramenta de desenvolvimento local, não precisam de nada disso: a própria especificação os isenta e aponta para credenciais de ambiente. Agentes internos que rodam atrás de VPN, consumidos só por um número fechado de pessoas da mesma empresa, também podem priorizar outras coisas antes, desde que ninguém pretenda abrir esse servidor para clientes MCP de terceiros.

O trade-off é de interoperabilidade: cada vez mais clientes MCP (de assistentes comerciais a frameworks de agentes open source↳Open source71 conteúdosComo o Open Source Está Liberando o Poder da Automação para TodosDev (Back & Front) · out 2025Código aberto: programadores criam software da NASA sem saberDev (Back & Front) · abr 2021N8N: O que é a ferramenta open source que está revolucionando a automação em TI?Dev (Back & Front) · dez 2025Ver tudo em Dev (Back & Front) →) já esperam encontrar a metadata de RFC 9728 e vão falhar silenciosamente contra um servidor que só entende token fixo. Um ponto que a própria especificação deixa em aberto é a escolha entre múltiplos authorization_servers listados na metadata: a responsabilidade de decidir qual usar fica explicitamente do lado do cliente, sem um critério padrão definido.

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