Autenticação MCP Explicada: Como Funciona e Por Que É Importante

A autenticação e autorização MCP nem sempre foram tão seguras como são hoje. Quando o MCP começou a ser implementado, a autenticação geralmente ocorria por meio de chaves de API, que eram frequentemente incluídas em um arquivo de configuração ou como variáveis de ambiente, permitindo assim acesso estático, compartilhado e sem escopo. Se essa chave fosse vazada, concederia a um usuário mal-intencionado acesso total, sem forma de rastrear ou controlar o que era feito.

A especificação MCP evoluiu rapidamente para resolver isso:

• Março de 2025: O OAuth 2.1 foi definido como o padrão para autenticar uma aplicação ou usuário contra uma API.
• Junho de 2025: Os servidores MCP foram redefinidos como servidores de recursos OAuth, e a capacidade de emitir tokens foi transferida para provedores de identidade externos.
• Novembro de 2025: O PKCE tornou-se obrigatório para todas as aplicações do lado do cliente, e o CIMD foi definido como uma forma de identificar unicamente cada instância de cliente.

Em menos de um ano, o método de autenticação MCP fez a transição de segredos estáticos para um modelo consistente com os sistemas de identidade empresariais modernos.

Este guia descreve o que é a autenticação MCP, como funciona, as possíveis abordagens para implementá-la, onde as implementações falham e como implementá-la corretamente em escala.

O Que É Autenticação MCP?

A autenticação MCP é o processo pelo qual um servidor MCP verifica a identidade de um solicitante antes de executar qualquer ferramenta.

Sem a autenticação MCP implementada, qualquer cliente MCP que pudesse alcançar um servidor MCP poderia invocar suas ferramentas, independentemente da identidade, função ou intenção desse cliente. Se as ferramentas invocadas estabelecessem uma conexão com sistemas externos críticos, como CRMs, bancos de dados ou serviços em nuvem, isso criaria um caminho irrestrito para dados sensíveis em produção.

Este não é um risco teórico. Uma vulnerabilidade CVSS 9.6 no pacote mcp-remote permitiu que servidores MCP maliciosos utilizassem o fluxo OAuth dentro do pacote para executar comandos arbitrários do sistema operacional remotamente, impactando centenas de milhares de downloads.

A autenticação MCP é realizada através da camada de transporte antes que a execução da ferramenta ocorra. A forma de execução depende de como o servidor MCP é implantado:

• Transporte STDIO (servidores locais): Executa como um processo local; a autenticação MCP pode usar variáveis de ambiente ou credenciais do sistema fora do MCP.
• HTTP Transmissível (servidores remotos): Funciona na rede sem confiança partilhada entre o cliente e o servidor MCP. A autenticação MCP ocorre usando OAuth 2.1 com tokens de acesso anexados a cada pedido.

Na prática:

• Desenvolvimento local: credenciais baseadas no ambiente podem ser suficientes.
• Sistemas de produção remotos: OAuth 2.1 é necessário para uma autenticação adequada.

Os Três Tipos de Autenticação MCP

Métodos de Autenticação utilizados em diferentes Implementações MCP, dependendo do Ambiente e da Tolerância ao Risco

Chaves de API e Tokens Estáticos

É um método simples de passar uma chave pré-acordada com cada pedido. 

Autorização: Bearer sk-xxxx

Quando funciona: 

• No desenvolvimento local e por uma ferramenta interna a operar dentro de um limite de rede bem definido.

Limitações: 

• Tokens estáticos não têm validade
• Tokens estáticos não têm identidade de utilizador
• Sem permissões granulares
• Tokens estáticos podem ser expostos através de registos ou controlo de versão, o que é bastante arriscado. 
• Quando os tokens estáticos são expostos, o controlo de acesso total ao sistema associado permanecerá ativo até ser desativado manualmente

OAuth 2.1 com PKCE (Padrão para Servidores MCP Remotos)

A partir da atualização da especificação MCP de março de 2025, o padrão para proteger servidores MCP remotos via autenticação MCP é OAuth 2.1 com PKCE. Em vez de credenciais estáticas, esta abordagem utiliza um fluxo de autorização seguro, baseado em tokens, que permite o HTTP Transmissível.

Como funciona:

• Descoberta de metadados: O cliente MCP tenta descobrir os metadados do servidor de autorização necessários do servidor sem um token de acesso e recebe uma resposta 401. O documento de metadados do recurso protegido informa ao cliente a qual servidor de autorização se conectar e quais escopos necessários estão disponíveis.
• Registro do cliente: O cliente MCP se registra no servidor de autorização. O método padrão desde novembro de 2025 é via protocolo CIMD. O cliente publica seus metadados de ID de cliente em uma URL pública que controla, e o servidor de autorização realiza a validação em tempo de execução das informações do cliente.
• Código de autorização: O cliente abre o navegador do usuário, solicita que o usuário faça login e dê consentimento, e recebe um código de autorização do servidor de autorização para agir em seu nome.
• Emissão de token de acesso: O cliente troca o código de autorização usando o fluxo de código de autorização por um token de acesso com escopo para o recurso solicitado, e inclui este token em cada solicitação MCP.

Por que o PKCE é importante:

• O PKCE protege contra ataques de interceptação, garantindo que o usuário que completa a autenticação MCP é a mesma pessoa que a iniciou.
• O PKCE é exigido para todos os clientes MCP a partir de novembro de 2025, conforme a especificação MCP atual.

Credenciais Baseadas no Ambiente (Servidores STDIO)

Servidores MCP locais herdam credenciais do seu próprio ambiente de execução.

Prós:

• Fácil de configurar, sem fluxo de autorização externo.

Contras:

• As credenciais são acessíveis a qualquer processo que pode acessar o sistema MCP, criando risco entre as fontes de dados.
• Difícil de gerenciar entre várias pessoas ou equipes sem lógica de autorização centralizada.
• Sem governança ou controle de acesso centralizado.

Em ambientes de Produção, você deve recuperar suas credenciais dinamicamente usando um cofre seguro, em vez de armazená-las em texto simples.

Como a Autenticação OAuth 2.1 do MCP Funciona Passo a Passo

Quando um cliente MCP se conecta a um servidor MCP protegido, o seguinte fluxo MCP ocorre:

• Passo 1 — Cliente se conecta, servidor rejeita: O cliente MCP tenta uma requisição sem token. O servidor responde com um erro 401 Não Autorizado e um ponteiro para a URL de metadados de seu recurso protegido como parte da descoberta do servidor de autorização.
• Passo 2 — Cliente recupera metadados: O endpoint de metadados especifica qual servidor de autorização usar, quais escopos OAuth estão disponíveis e onde localizar o endpoint de token.
• Passo 3 — Cliente se registra e inicia o fluxo OAuth: O cliente se identifica usando CIMD e seu documento de metadados de ID de cliente, cria um verificador de código PKCE e um desafio de código, e então redireciona o navegador do usuário para a página de login do servidor de autorização.
• Passo 4 — Usuário autentica e recebe o código de autorização: O usuário faz login e consente. O servidor de autorização retorna um código de autorização para o cliente trocar, usando o verificador de código original, por um token de acesso de curta duração e com escopo definido.
• Passo 5 — Cliente chama o servidor MCP com token bearer: Cada requisição MCP inclui o token de acesso no cabeçalho Authorization Bearer. O servidor MCP valida o emissor, a audiência, a expiração e os escopos OAuth. Se o token de acesso tiver escopos requeridos insuficientes, o servidor responde com um 403 e solicita autorização adicional do usuário, uma capacidade introduzida em novembro de 2025.

Onde a Autenticação MCP Ainda Falha?

Muitas implementações criam sérios riscos de segurança MCP através de uma implementação inadequada de autenticação e autorização MCP, mesmo ao usar OAuth.

• Tokens estáticos em arquivos de configuração: Chaves de API commitadas em repositórios Git, compartilhadas em arquivos mcp.json ou .env, e esquecidas. Um único ID de cliente OAuth comprometido fornece acesso ilimitado e nunca expira, criando uma fonte persistente de acesso não autorizado.
• Escopos OAuth com permissões excessivas: Os usuários solicitam um grande número de escopos OAuth durante a configuração, mas não os restringem ao executar o aplicativo. Um agente de IA configurado como somente leitura deve ser armazenado com um token de acesso com escopo de leitura, em vez de um token de leitura/escrita/exclusão.
• Sem rotação de token em implantações autogerenciadas: Tokens OAuth de longa duração emitidos para implantações autogerenciadas sem processo de rotação. Se um token for comprometido, ele permanece funcional como um token bearer válido até que alguém o desative manualmente.
• Ausência de trilha de auditoria para chamadas de ferramentas: Quando um token é emitido e ferramentas externas são acessadas, não há registro indicando quem fez a solicitação MCP original, tornando a investigação da causa raiz impossível para os membros da equipe de segurança.

A maioria desses problemas é resolvida quando as organizações migram de chaves estáticas para OAuth 2.1, o que permite tokens de acesso de curta duração, escopos OAuth delimitados e registro de auditoria centralizado através do servidor de autorização.

Requisitos de Autenticação MCP Empresarial vs. Como a TrueFoundry os Resolve

A TrueFoundry remove a complexidade de gerenciar múltiplas formas de autenticação e autorização MCP entre equipes individuais e aplica controles uniformes em todos os servidores MCP através de uma única camada de gateway MCP.

Agende uma demonstração para entender como o MCP lida com a autenticação no nível da infraestrutura

Perguntas Frequentes

O que é autenticação MCP? 

A autenticação MCP é o processo de verificar a identidade de uma entidade que tenta se conectar a um servidor MCP, usando tokens OAuth, chaves de API ou variáveis de ambiente, dependendo do contexto de implantação. Ela permite que apenas agentes de IA verificados e clientes MCP acessem ferramentas e serviços externos, formando a primeira camada de autenticação e autorização MCP em qualquer sistema de produção.

O MCP exige OAuth? 

Nem em todos os casos. Um servidor de transporte STDIO local pode não implementar um fluxo OAuth formal. No entanto, qualquer servidor MCP remoto que lida com dados sensíveis de produção ou ferramentas externas deve usar OAuth 2.1 com PKCE como o mecanismo de autorização padrão sob a especificação MCP atual para a aplicação adequada da autenticação e autorização MCP.

O MCP possui autenticação? 

O MCP suporta autenticação e autorização MCP, e o método depende do ambiente do servidor. Servidores remotos usam OAuth 2.1 PKCE como o fluxo de autorização padrão. Servidores de transporte STDIO locais autenticam usando credenciais de variáveis de ambiente ou do processo host. A especificação MCP formalmente exigiu OAuth 2.1 como o padrão para implantações remotas a partir de março de 2025.

Quais são os tipos de autenticação MCP? 

Existem três métodos comuns para autenticação e autorização MCP: chaves de API estáticas para casos de uso internos ou de desenvolvimento, OAuth 2.1 com PKCE para todas as implantações de servidor MCP remoto, conforme exigido pela especificação MCP, e credenciais baseadas em ambiente via variáveis de ambiente para servidores de transporte STDIO locais onde um fluxo formal de registro de cliente OAuth não é exigido.

Como funciona a autenticação MCP? 

Quando um cliente MCP se conecta a um servidor MCP protegido, o servidor retorna um 401 com um ponteiro para seu documento de metadados de recurso protegido. O cliente realiza a descoberta do servidor de autorização, registra-se usando CIMD, completa o fluxo de código de autorização com PKCE e recebe um token de acesso com escopo. Este token é incluído em cada solicitação de entrada para validação do token antes que qualquer chamada de ferramenta seja permitida.

Como a TrueFoundry lida com a autenticação MCP? 

Através do gateway MCP, a TrueFoundry centraliza a autenticação e autorização MCP integrando-se com provedores de identidade corporativos e gerenciando a emissão, rotação e validação automatizadas de tokens de acesso. Escopos OAuth e políticas RBAC são aplicados na camada do gateway em todos os servidores MCP, com logs de auditoria estruturados retidos dentro da VPC do cliente para conformidade entre agentes de IA e serviços externos.