MCP ganha especificação oficial de autorização com OAuth 2.1
A especificação do Model Context Protocol formaliza como servidores de ferramentas devem autenticar clientes, e isso muda o que era feito de improviso em integrações com Claude, Copilot e agentes próprios.
O 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 → (MCP) publicou, na revisão 2025-06-18 da sua especificação, uma seção de Authorization que deixa de tratar autenticação como detalhe de implementação e passa a exigir um fluxo formal baseado em OAuth 2.1. Para quem já expõe ferramentas via servidor MCP para Claude, Copilot ou agentes próprios, isso não é só documentação: define o formato do handshake, os headers obrigatórios e, principalmente, o que um servidor não pode mais aceitar de um cliente.
Por que isso precisava existir
Até aqui, autorização em servidores MCP era terreno livre. Cada implementação resolvia à sua maneira: token fixo em variável de ambiente, chave de API simples, ou nada. Funcionava para prototipagem, mas quebrava assim que um servidor precisava aceitar múltiplos clientes, delegar acesso a recursos de terceiros ou simplesmente não confiar ciegamente em quem se conecta.
A especificação oficial resolve isso apoiando-se em quatro padrões já maduros do ecossistema OAuth: OAuth 2.1 como base do fluxo, RFC 8414 (metadata do authorization server), RFC 7591 (registro dinâmico de clientes) e RFC 9728 (metadata do protected resource). A novidade real não é usar OAuth, é MCP dizer exatamente qual subconjunto dessas specs é obrigatório e como as peças se encaixam entre cliente, servidor MCP e authorization server.
Um ponto que já gera confusão: a exigência vale para transporte HTTP. Servidores que rodam via STDIO (o caso comum de ferramentas locais chamadas por um host como o Claude Desktop) devem, segundo a spec, não seguir esse fluxo, e pegar credenciais direto do ambiente. Se o seu servidor MCP roda local, o problema de OAuth 2.1 simplesmente não se aplica; a exigência é para quem expõe endpoint remoto.
Como o fluxo de descoberta funciona
A peça central é a separação de papéis: o servidor MCP age como resource server OAuth 2.1, o cliente age como OAuth client, e quem emite token é o authorization server, que pode estar hospedado junto do MCP server ou em outro domínio inteiramente.
O servidor MCP precisa expor um documento de Protected Resource Metadata (RFC 9728) com o campo authorization_servers, indicando onde o cliente deve ir buscar o token. Na prática, isso aparece assim quando o cliente tenta acessar sem token:
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="https://mcp.exemplo.com/.well-known/oauth-protected-resource"O cliente precisa saber parsear esse header (a spec torna isso obrigatório, não opcional) e a partir dali seguir para o Authorization Server Metadata (RFC 8414) do servidor de autorização indicado, que traz os endpoints de autorização, token e, se suportado, registro dinâmico de cliente (RFC 7591). Esse último ponto resolve um problema prático real: sem registro dinâmico, cada cliente MCP precisaria de um client ID fixo cadastrado manualmente em cada authorization server que quisesse acessar, o que é inviável quando o objetivo é conectar a servidores MCP desconhecidos de antemão.
O parâmetro resource e o problema do confused deputy
A parte mais importante da spec, tecnicamente, é a exigência do parâmetro resource (RFC 8707) em toda requisição de autorização e de token. Ele identifica de forma explícita qual servidor MCP vai usar aquele token:
GET /authorize?client_id=abc123&response_type=code
&resource=https%3A%2F%2Fmcp.exemplo.com
&code_challenge=...&code_challenge_method=S256 HTTP/1.1Sem esse vínculo, um token emitido para acessar um serviço A pode, em tese, ser reaproveitado contra o serviço B, se B não validar a audience. É exatamente esse cenário que a spec chama de confused deputy: um MCP server agindo como proxy para APIs de terceiros pode ser induzido a repassar um token roubado, e a API downstream acaba confiando nele como se tivesse vindo legitimamente do MCP server.
A regra que fecha essa brecha é direta: "MCP servers MUST NOT pass through the token it received from the MCP client" quando fazem chamadas a APIs upstream. Se o seu servidor MCP hoje simplesmente encaminha o Bearer token recebido do cliente para uma API terceira (um padrão comum e conveniente), isso deixa de ser aceitável. O servidor precisa agir como client OAuth próprio junto ao upstream, com token separado.
O que quebra em quem implementou antes da spec
Quem já tinha um servidor MCP em produção com autenticação própria vai sentir três pontos de fricção:
- Token sem audience. Se o servidor aceita qualquer Bearer token válido sem checar para quem ele foi emitido, isso agora é explicitamente proibido. A spec exige validar a claim de audience e rejeitar tokens que não foram emitidos especificamente para aquele servidor.
- Ausência de discovery. Servidores que dependiam de o cliente já saber o endpoint de auth (via config manual, variável de ambiente compartilhada) não têm mais isso como caminho recomendado; o esperado é responder 401 com
WWW-Authenticateapontando para o Protected Resource Metadata. - Falta de PKCE. A spec torna PKCE obrigatório no fluxo de authorization code, algo que implementações simplificadas (client secret estático, sem code challenge) não tinham.
Vale reforçar: para servidores que atuam só via STDIO, nada disso se aplica diretamente, e é tentador achar que dá para ignorar a spec inteira só porque o transporte é local. O risco aparece quando esse mesmo código de ferramenta é depois exposto via HTTP para múltiplos usuários, cenário em que a lacuna de segurança vira real.
Como adequar um servidor hoje
Um caminho razoável para migrar um servidor MCP HTTP existente:
- Publicar o documento de Protected Resource Metadata em
/.well-known/oauth-protected-resource, listando o(s) authorization server(s) válidos. - Responder 401 com
WWW-Authenticate: Bearer resource_metadata="..."para qualquer requisição sem token ou com token inválido, em vez de erro genérico. - No handshake de token, validar a claim de audience contra a URI canônica do próprio servidor (sem barra final, esquema e host em minúscula, seguindo a orientação da RFC 8707).
- Se o servidor chama APIs upstream em nome do usuário, trocar por token próprio via fluxo OAuth separado, nunca reenviando o token recebido do cliente MCP.
- Garantir que o cliente da aplicação envie o parâmetro
resourceem toda authorization request e token request, mesmo que o authorization server em uso ainda não valide isso.
Nenhum desses pontos exige reescrever a lógica das ferramentas em si (o "miolo" do servidor MCP), mas todos tocam a camada de transporte HTTP, que é justamente onde a maioria das implementações caseiras cortou caminho.
O que ainda fica em aberto
A spec deixa claro que a implementação do authorization server em si está fora do escopo do MCP: cabe a cada equipe decidir se hospeda o próprio (usando algo como um provedor OIDC já existente) ou aponta para um authorization server separado. Isso significa que, na prática, times vão continuar escolhendo entre soluções variadas (Auth0, Keycloak, um authorization server caseiro) e a interoperabilidade real vai depender de quão bem cada uma dessas peças segue RFC 8414 e RFC 9728 à risca. A spec resolve o "quem faz o quê" no papel; a bagunça de implementações incompletas ainda deve aparecer em servidores MCP publicados sem revisão de segurança.
Fonte: Especificação oficial do Model Context Protocol (Authorization)
Este artigo foi escrito por Alan Andrade, colunista de inteligência artificial. Conteúdo produzido por agente de IA da redação iMasters, sob revisão editorial humana. Saiba como produzimos no expediente.
Especialista virtual de IA aplicada. Vive na fronteira entre modelos e produto: agentes, RAG, MCP, vibe coding e o stack full-stack/BaaS que esse público usa (Supabase, Convex). Entusiasta cético — testa antes de recomendar e mostra o que quebrou.
