Cibersegurança · Segurança MCP · 8 min
Tokens, OAuth e “confused deputy”: evitar acessos não autorizados
Quando um servidor age em nome de uma pessoa perante outro serviço, deve preservar a identidade, o consentimento e o escopo de cada autorização.
Introdução
Um token não é apenas uma cadeia que permite “conectar” um serviço: representa uma autoridade delimitada. Em sistemas com proxies ou integrações encadeadas, a confusão sobre quem essa autoridade representa pode transformar o servidor em um confused deputy.
O que o MCP especifica e o que não especifica
A autorização MCP é opcional. Para implementações que a oferecem sobre HTTP, a especificação 2025-11-25 define um fluxo baseado em OAuth e exige, entre outros pontos, que o servidor implemente Protected Resource Metadata (RFC 9728) e que o cliente a use para descobrir servidores de autorização. O servidor atua como resource server e o cliente como OAuth client. Não se deve extrapolar automaticamente esse fluxo para stdio: a especificação recomenda não usá-lo ali e recuperar as credenciais do ambiente.
Essas obrigações são específicas do mecanismo de autorização descrito pelo MCP. Não substituem a análise da autorização entre o servidor MCP e uma API de terceiros.
Evitar o “confused deputy”
O risco aparece, por exemplo, quando um proxy usa suas próprias credenciais para uma API externa, mas não verifica adequadamente a qual cliente MCP está atendendo nem preserva uma aprovação individual. As boas práticas do MCP descrevem um cenário particular que combina um identificador OAuth estático, registro dinâmico de clientes, um cookie de consentimento de terceiros e ausência de consentimento por cliente. Isso não implica que todo fluxo OAuth do MCP seja vulnerável.
Vincule cada fluxo ao seu cliente e usuário; valide redirect_uri, estado e destino; não reutilize tokens entre usuários ou clientes; solicite consentimento claro antes de delegar; restrinja scopes e audiência; proteja os tokens no armazenamento e nos logs. Aplique também a RFC 9700, Best Current Practice do OAuth 2.0, como guia de segurança do OAuth, sem confundi-la com uma especificação do MCP.
Conclusão
A pergunta-chave não é apenas “há token?”, e sim “quem o obteve, para qual recurso, em nome de quem e sob qual consentimento?”. Preserve essas relações ao longo de cada salto.
Fontes e rigor
Referências
Referências verificadas em 25 de setembro de 2026. A especificação pode mudar; confira as versões vigentes antes de tomar decisões de implementação.
Conclusão
A pergunta-chave não é apenas “há token?”, e sim “quem o obteve, para qual recurso, em nome de quem e sob qual consentimento?”. Preserve essas relações ao longo de cada salto.
Continue explorando