MCP e OAuth 2.1: como blindar servidores que expõem dados internos a agentes de IA

Conectar um agente de IA↳Agentes de IA42 conteúdosOpera passa a integrar ChatGPT, Claude e outros agentes de IADev (Back & Front) · mar 2026Operações mais inteligentes, decisões mais rápidas: o impacto da IA agêntica na rotina de TIAI · abr 2026Adobe aposta em orquestração de agentes de IA: o que muda para devsDev (Back & Front) · abr 2026Ver tudo em AI → a dados internos parece simples até a primeira pergunta desconfortável: quem autorizou esse acesso e como o servidor tem certeza de que o token que chegou foi emitido para ele, e não para outro serviço? A especificação de autorização do Model Context Protocol na versão 2025-06-18 responde a isso adotando um subconjunto de OAuth 2.1 no nível do transporte HTTP. E, diferente de versões anteriores do MCP, o desenho separa claramente os papéis de servidor de recursos e servidor de autorização.

O ponto que merece atenção de quem constrói no Brasil é que a spec não é hype de segurança genérica: ela lista requisitos com MUST e MUST NOT que, se ignorados, transformam um servidor MCP em vetor de vazamento. Vale destrinchar o que realmente muda.

Os três papéis: recurso, cliente e servidor de autorização

A especificação mapeia tudo para OAuth 2.1. Um servidor MCP protegido atua como resource server: aceita requisições autenticadas por access token e responde. O cliente MCP (o host do agente) atua como OAuth client, fazendo requisições em nome do dono do recurso. E o authorization server, que emite os tokens, é uma entidade à parte, que pode estar hospedada junto do resource server ou separada. A implementação dele fica, deliberadamente, fora do escopo da spec.

Um detalhe operacional importante: autorização é opcional no MCP. Se o transporte é STDIO (o servidor rodando local, comunicando por stdin/stdout), a spec diz explicitamente que ele não deve seguir esse fluxo, e sim buscar credenciais do ambiente. O OAuth 2.1 entra em cena quando o transporte é HTTP, ou seja, quando o servidor MCP está exposto na rede, exatamente o caso de expor dados internos a agentes remotos.

Descoberta: como o cliente encontra o servidor de autorização

O fluxo começa com o cliente sem saber onde autenticar. A spec resolve isso com metadados padronizados:

• O servidor MCP deve implementar OAuth 2.0 Protected Resource Metadata (RFC 9728), com o campo authorization_servers apontando ao menos um servidor de autorização.
• Quando o cliente bate sem token, o servidor responde 401 Unauthorized com o header WWW-Authenticate indicando a URL dos metadados do recurso.
• O cliente deve saber parsear esse header e, a partir dele, descobrir o servidor de autorização e seus endpoints via OAuth 2.0 Authorization Server Metadata (RFC 8414).

Na prática, isso significa que o cliente MCP não precisa de configuração manual prévia: ele descobre onde autenticar reagindo ao 401. A spec ainda recomenda (SHOULD) suporte a Dynamic Client Registration (RFC 7591), para que o cliente obtenha um client_id sem intervenção humana, algo que reduz atrito quando o agente encontra servidores MCP novos.

O parâmetro resource: a peça que evita o token confuso

Aqui está o que separa um servidor MCP seguro de um vulnerável. A spec obriga (MUST) o cliente a implementar Resource Indicators for OAuth 2.0 (RFC 8707), incluindo o parâmetro resource tanto no pedido de autorização quanto no de token. Esse parâmetro amarra o token ao servidor MCP específico onde ele será usado.

O valor precisa ser a URI canônica do servidor. A spec dá exemplos válidos e inválidos:

Na requisição de autorização, isso aparece codificado assim:

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

E o cliente deve enviar esse parâmetro mesmo que o servidor de autorização não o suporte, para garantir adoção futura.

Validação no servidor: audiência e a proibição do passthrough

Do lado do servidor MCP, a regra é dura. Todo access token chega no header, nunca na query string:

GET /mcp HTTP/1.1
Host: mcp.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

O servidor deve validar que o token foi emitido especificamente para ele, verificando a claim de audiência (aud), conforme RFC 8707 e RFC 9068. Token com audiência errada recebe 401. Escopo insuficiente devolve 403. Requisição malformada, 400.

O trecho mais importante para quem monta arquitetura com 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) → próprio é a proibição explícita de token passthrough. Se o servidor MCP precisa consultar uma API upstream (digamos, o Supabase), ele age como cliente OAuth daquela API e usa um token separado, emitido pelo servidor de autorização do upstream. A spec é categórica:

A MCP server MUST NOT pass through the token it received from the MCP client.

Encaminhar o token do cliente adiante é o clássico confused deputy: a API downstream passa a confiar num token que nunca foi validado para ela, e um atacante reutiliza credenciais legítimas cruzando serviços. Aceitar tokens de audiência errada e repassá-los são, segundo a spec, as duas dimensões críticas dessa vulnerabilidade.

Um caso concreto: servidor MCP em Node.js sobre Supabase

Pense no cenário do ângulo desta pauta: um agente que precisa consultar pedidos internos guardados no Postgres↳PostgreSQL11 conteúdosPostgreSQL via SSL com GolangData · abr 20195 itens legais sobre data types do PostgreSQLData · mar 20195 serviços gratuitos na cloud para bancos de dados PostgresData · fev 2025Ver tudo em Data → do Supabase. O caminho que faz sentido seguir, respeitando a spec:

1. O servidor MCP (HTTP) publica seus Protected Resource Metadata e responde 401 com WWW-Authenticate quando não há token.
2. O cliente descobre o authorization server, faz o fluxo de code com PKCE e obtém um token cuja audiência é a URI canônica do servidor MCP, via parâmetro resource.
3. O servidor MCP recebe o Bearer, valida assinatura, expiração e, sobretudo, que aud corresponde a ele mesmo.
4. Para ler do Supabase, o servidor não usa o token do agente. Ele usa sua própria credencial de serviço (a service_role ou uma chave dedicada guardada em variável de ambiente), aplicando as regras de Row Level Security que fazem sentido para aquele contexto.

Esse passo 4 é onde muita implementação apressada erra. A tentação de repassar o token do usuário direto ao Supabase economiza código, mas viola a spec e mistura as fronteiras de confiança. O correto é o servidor MCP mediar: valida quem chama, decide o que expor e consulta o backend com credencial própria, retornando só o que aquele consentimento autoriza.

PKCE, tokens curtos e redirecionamento: o resto da conta

As Security Considerations fecham o desenho:

• PKCE é obrigatório para o cliente, prevenindo interceptação e injeção de authorization code.
• Servidores de autorização devem emitir tokens de vida curta, e para clientes públicos devem rotacionar refresh tokens, reduzindo o estrago de um vazamento.
• Todos os endpoints em HTTPS; redirect URIs só localhost ou HTTPS, e validados por correspondência exata contra valores pré-registrados, para barrar open redirect e phishing.
• O cliente deve usar e verificar o parâmetro state, descartando respostas cujo state não bata.

Quando não vale a pena

Se o servidor MCP roda local via STDIO, dentro da máquina do próprio usuário, montar esse aparato OAuth 2.1 é overhead sem retorno: a spec manda usar credenciais do ambiente. O fluxo de autorização só se justifica quando o transporte é HTTP e o servidor está exposto a clientes remotos, que é justamente o caso de expor dados corporativos a agentes de terceiros. Para quem está nessa situação, a especificação não deixa margem para atalho: audiência validada, PKCE e zero passthrough são requisitos, não sugestões.

Fonte: Especificação oficial do Model Context Protocol (Authorization)