Autenticação MCP: Como Garantimos 12 Servidores MCP Sem Perder a Cabeça

TL;DR: A autenticação MCP é genuinamente mais complexa do que a autenticação de API regular porque você está gerenciando credenciais em muitos servidores, para muitos agentes, sob muitas identidades de usuário - muitas vezes tudo de uma vez. As abordagens variam de chaves de API estáticas (rápidas, inseguras em grande escala) a OAuth 2.1 com PKCE (compatível com especificações, mais configuração) a um gateway centralizado que lida com toda a autenticação downstream para você. Passamos por todas as três etapas. Este post cobre o que aprendemos.

Oito meses atrás, nossa história de autenticação MCP era: chave de API compartilhada em um .env arquivo, cada desenvolvedor tinha acesso a tudo, dedos cruzados para que nada de ruim acontecesse.

Duas quase falhas depois - um agente que quase deletou dados de produção através de uma ferramenta de escrita mal configurada, um contratado cujo acesso ao MCP não foi revogado após sua saída - levamos isso a sério.

Aqui está a configuração que encontramos, o que cada parte resolveu e quanto custou em tempo de configuração.

Por que a autenticação MCP é mais difícil do que a autenticação de API regular

A autenticação de API regular tem um relacionamento de credencial: seu aplicativo se autentica em um serviço. A autenticação MCP tem três:

Cliente → Gateway/Servidor: como seu agente prova sua identidade para a infraestrutura MCP
Gateway → Serviço downstream: como o servidor MCP se autentica no GitHub, Jira, Slack ou qualquer backend que ele envolva
Delegação de usuário: quando um agente atua em nome de um humano específico (publicar no Slack como um usuário, não como um bot), como a identidade desse usuário flui através da cadeia de chamadas

Gerenciar todos os três manualmente, por servidor, por desenvolvedor, por agente é onde a complexidade explode. A maioria dos problemas de autenticação MCP são problemas de coordenação, não problemas de criptografia.

Os métodos de autenticação, em ordem de complexidade

Chaves de API estáticas / Tokens Bearer

A opção mais simples. O servidor MCP espera um token Bearer estático no cabeçalho Authorization. Você o configura uma vez na configuração do servidor e novamente na configuração do cliente. Feito.

{
  "mcpServers": {
    "my-server": {
      "url": "https://my-mcp-server.internal/mcp",
      "headers": {
        "Authorization": "Bearer your-static-token-here"
      }
    }
  }
}

Onde funciona: Servidores internos com um único operador, ambientes de desenvolvimento, protótipos rápidos.

Onde falha: Rotação. Cada vez que o token muda, cada cliente que o utiliza precisa ser atualizado. Com 15 desenvolvedores e 8 servidores, a rotação de tokens se torna um pesadelo de coordenação. E se o token estiver em um arquivo .env em um repositório, eventualmente estará no histórico do git.

O verdadeiro risco: Tokens estáticos não têm identidade de usuário anexada. Quando um agente chama uma ferramenta usando um token estático, não há como saber qual desenvolvedor ou fluxo de trabalho o acionou. As trilhas de auditoria se tornam "token X chamou a ferramenta Y no tempo Z" - inútil para conformidade ou resposta a incidentes.

Variáveis de ambiente para servidores stdio

Servidores MCP baseados em stdio são executados como processos locais. A autenticação acontece fora do protocolo MCP - você passa credenciais como variáveis de ambiente que o servidor lê na inicialização.

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "${env:GITHUB_TOKEN}"
      }
    }
  }
}

A sintaxe ${env:VAR} no Claude Code e Cursor puxa do seu ambiente de shell em vez de codificar o valor no arquivo de configuração - isso mantém as credenciais fora do controle de versão.

Onde funciona: Desenvolvimento local com servidores stdio onde cada desenvolvedor se autentica com suas próprias credenciais.

Onde falha: Não escala. Cada desenvolvedor gerencia suas próprias credenciais por servidor. Não há revogação centralizada. Quando um desenvolvedor sai, você espera que ele tenha limpado seu ambiente local (geralmente não o fez).

OAuth 2.1 com PKCE para servidores remotos

A especificação MCP padronizou OAuth 2.1 com PKCE em sua revisão de março de 2025. Esta é a resposta correta a longo prazo para servidores MCP remotos porque vincula chamadas de ferramentas a identidades de usuários reais através do seu provedor de identidade existente.

O fluxo:

1. Agente inicia uma conexão MCP
2. Servidor redireciona para seu IdP (Okta, Azure AD, Auth0)
3. Usuário se autentica no navegador
4. IdP emite um código de autorização
5. Cliente troca o código por um token de acesso (PKCE garante que isso não pode ser interceptado)
6. Token é anexado a todas as chamadas MCP subsequentes

O que isso lhe dá: Chamadas de ferramentas estão ligadas ao usuário autenticado, não a uma credencial de serviço compartilhada. Tokens expiram e são autoatualizados. Revogar o acesso de um usuário em seu IdP revoga automaticamente seu acesso ao MCP.

O que isso custa: Mais configuração. Seu servidor MCP precisa implementar o lado do servidor de recursos OAuth. Seu cliente precisa lidar com o fluxo de redirecionamento do navegador. Nem todos os clientes MCP implementaram totalmente a revisão da especificação de novembro de 2025 ainda - verifique o suporte OAuth do cliente específico antes de depender dele.

PATs e VATs para contas de serviço

Para agentes de produção que operam sem intervenção humana (sem redirecionamento de navegador possível), o padrão é Tokens de Acesso Pessoal (PATs) para usuários individuais e Tokens de Conta Virtual (VATs) para contas de serviço.

• PAT: vinculado à identidade de um usuário específico, apropriado para fluxos de trabalho de desenvolvimento e ações delegadas por usuários
• VAT: uma credencial de conta de serviço com permissões definidas, apropriada para agentes automatizados em execução em produção sem um usuário humano anexado

A distinção é importante para aud