Autenticação em servidor MCP: OAuth, tokens e permissões

Autenticação em servidor MCP: OAuth, tokens e permissões

Para autenticar clientes em um servidor MCP corporativo, trate o servidor como um resource server OAuth: ele não emite tokens, apenas valida os que um servidor de autorização da empresa (o seu provedor de identidade) emitiu para ele. O cliente descobre onde se autenticar, obtém um token com escopos mínimos e o servidor confere emissor, destinatário, validade e escopo a cada chamada. A revogação funciona quando os tokens são curtos e o acesso pode ser cortado no provedor de identidade.

Principais pontos

• A especificação do MCP trata a autorização como opcional para transportes HTTP e se apoia em OAuth 2.1. Se o servidor é remoto e acessa dados da empresa, trate como obrigatória.
• O servidor MCP valida tokens, o provedor de identidade emite. Misturar os dois papéis cria um segundo sistema de login para manter e auditar.
• Escopo não é permissão. O escopo limita o que o cliente pode pedir, mas o servidor ainda precisa checar o que aquele usuário pode fazer no sistema de origem.
• Nunca repasse ao sistema interno o mesmo token que o cliente enviou. Use credenciais próprias do servidor para a chamada seguinte.
• Revogar é um procedimento, não um botão que existe por acaso. Defina antes quem corta o acesso, onde e em quanto tempo ele deixa de valer.

O que a especificação do MCP diz sobre autenticação?

A documentação do protocolo está em modelcontextprotocol.io, e a seção de autorização da especificação é a referência para este tema. Vale separar o que é texto oficial do que é interpretação, e este artigo faz isso ao longo das seções.

Do lado da documentação oficial, os pontos mais relevantes para uma empresa são estes:

• A autorização é opcional. Servidores com transporte HTTP que a implementam devem seguir a especificação. Servidores locais, por entrada e saída padrão (stdio), normalmente pegam credenciais do ambiente em vez de rodar um fluxo OAuth.
• O servidor MCP age como resource server OAuth. O cliente MCP age como cliente OAuth. O servidor de autorização pode ser separado do servidor MCP, e na prática empresarial deve ser.
• O servidor publica metadados de recurso protegido, indicando qual servidor de autorização aceita. Quando recebe uma chamada sem token válido, responde com 401 e um cabeçalho que aponta para esses metadados.
• O cliente usa o fluxo de código de autorização com PKCE e informa, no pedido, para qual recurso (qual servidor MCP) o token será usado. Isso amarra o token ao destinatário.
• O servidor deve aceitar apenas tokens emitidos para ele e não pode repassar o token recebido a APIs de terceiros. A especificação chama esse erro de token passthrough.
• O token vai no cabeçalho Authorization de cada requisição, nunca na URL.

O texto de autorização do MCP evoluiu entre versões da especificação. Antes de projetar, confirme qual versão seu cliente e seu servidor implementam e releia a seção correspondente. Para os conceitos gerais do fluxo, a documentação de OAuth 2.0 do Google é uma referência neutra e didática.

Como desenhar o fluxo de autenticação passo a passo?

O plano abaixo combina o que a especificação descreve com recomendações de implementação. As recomendações estão marcadas como tal.

• Passo 1: escolha o servidor de autorização. Use o provedor de identidade que a empresa já tem (login corporativo, com autenticação em dois fatores). Recomendação de implementação: não construa emissão de tokens dentro do servidor MCP.
• Passo 2: registre o cliente. A especificação prevê registro dinâmico de clientes e também clientes pré-registrados. Recomendação: em ambiente corporativo, prefira pré-registro de cada cliente aprovado, com redirect URIs exatas, para que um cliente desconhecido não consiga iniciar um fluxo.
• Passo 3: publique os metadados do recurso protegido e faça o servidor responder 401 com a indicação correta quando faltar token. Isso permite que clientes compatíveis descubram o login sozinhos.
• Passo 4: exija PKCE e o parâmetro de recurso no pedido de token. Assim o token nasce com o servidor MCP como destinatário.
• Passo 5: valide em toda chamada o emissor, o destinatário, a expiração e os escopos. Rejeite o que não bater, sem mensagens de erro que revelem detalhes internos.
• Passo 6: defina tempos de vida curtos para o token de acesso e rotação para o token de renovação. O prazo exato depende do seu risco, e deve ser decisão registrada, não padrão herdado.
• Passo 7: registre cada decisão de autorização em log (quem, qual cliente, qual ferramenta, permitido ou negado), sem gravar o conteúdo do token nem dados pessoais desnecessários.

Se o servidor ainda está sendo planejado, o artigo Como criar servidor MCP para o sistema interno: leitura primeiro ajuda a decidir quais ferramentas existem antes de decidir quem pode chamá-las.

Como limitar escopos e permissões de verdade?

O erro mais comum é tratar um único escopo amplo, algo como acesso total, como solução provisória que vira definitiva. O princípio de menor privilégio descrito no guia de autorização da OWASP se aplica diretamente: negar por padrão e conceder o mínimo necessário para a tarefa.

Um desenho que costuma funcionar tem três camadas:

• Escopos por domínio e por tipo de ação. Separe leitura de escrita, por exemplo pedidos:ler e reembolso:solicitar, em vez de um escopo genérico por sistema.
• Autorização por ferramenta no servidor. Cada ferramenta declara qual escopo exige. Se o token não tem, a chamada falha antes de tocar o sistema interno.
• Autorização por dado. Mesmo com o escopo certo, o servidor confere se aquele usuário pode ver aquele registro. Um vendedor com escopo de leitura de clientes não deve enxergar a carteira de outro vendedor só porque o escopo permite.

A especificação prevê que o servidor indique os escopos necessários e que o cliente peça mais escopo quando uma ação exigir, o que permite começar com leitura e subir só quando necessário. Recomendação de implementação: ações que alteram dinheiro, estoque, cadastro ou comunicação com o cliente devem exigir, além do escopo, uma aprovação humana registrada. Isso conversa com o que explicamos em Guardrails para agentes de IA: entrada, saída e ação na prática.

Outra regra: o modelo de linguagem não é fronteira de segurança. Um texto malicioso dentro de um documento pode induzir o agente a pedir uma ação indevida (a OWASP descreve esse risco na lista de riscos para aplicações com LLM). Por isso a barreira precisa estar no servidor, com token e escopo, e não nas instruções do prompt.

Por que não repassar o token do usuário ao sistema interno?

A tentação é simples: o cliente enviou um token, o servidor MCP o encaminha ao ERP ou ao CRM e pronto. A especificação proíbe esse padrão por boas razões. O token foi emitido para o servidor MCP, não para o ERP. Se o ERP o aceita, qualquer cliente comprometido passa a ter um caminho indireto e o rastro de auditoria perde o sentido, porque o sistema final não sabe quem de fato originou a chamada.

O desenho correto é de duas etapas. O servidor valida o token recebido e identifica o usuário e os escopos. Depois, para falar com o sistema interno, usa uma credencial própria, com permissões mínimas e armazenada como segredo, ou realiza uma troca de token no provedor de identidade quando ele suporta isso. Recomendação de implementação: registre no log o usuário original junto com a chamada ao sistema interno, para que a rastreabilidade não se perca.

A credencial própria do servidor também precisa de ciclo de vida: onde fica guardada, quem pode lê-la, quando é trocada. O artigo Chaves de API em agentes de IA: onde guardar e como rotacionar cobre esse lado.

Como revogar acesso quando alguém sai ou algo dá errado?

Revogar acesso tem quatro camadas, e convém ter as quatro prontas antes do primeiro incidente:

• Desativar o usuário no provedor de identidade. Quando a pessoa deixa a empresa, nenhum novo token deve ser emitido e os tokens de renovação devem ser invalidados.
• Revogar tokens de renovação e sessões de um cliente específico. Útil quando um notebook é perdido ou um cliente MCP é comprometido, sem afetar os demais.
• Deixar o token de acesso expirar rápido. Como o servidor valida o token localmente, ele só descobre a revogação quando o token vence, a menos que consulte o provedor. Por isso o tempo de vida curto é parte do desenho de revogação, e não só de segurança geral.
• Chave geral no servidor. Uma lista de bloqueio por usuário ou por cliente e uma opção de desligar ferramentas de escrita com uma única configuração, para o caso de o problema ser o comportamento do agente e não a credencial.

Defina também quem tem autoridade para acionar cada camada e em que prazo. Em uma ocorrência com dados pessoais, o time jurídico e o encarregado de dados vão precisar dos logs; vale conferir as orientações da ANPD e alinhar o que é registrado com a LGPD, guardando o necessário e nada além.

Cenário ilustrativo: servidor MCP de pedidos para um agente de atendimento

Imagine uma distribuidora que quer um agente respondendo clientes sobre pedidos, inclusive pelo WhatsApp. O servidor MCP expõe três ferramentas: consultar pedido, consultar cliente e solicitar reembolso. Este é um cenário ilustrativo, sem relação com empresa real.

O desenho aplicado seria este:

• O login corporativo da distribuidora é o servidor de autorização. O cliente MCP do agente é pré-registrado, com redirect URI fixa.
• Os escopos são pedidos:ler, clientes:ler e reembolso:solicitar. O agente de atendimento recebe apenas os dois primeiros por padrão.
• A ferramenta de reembolso só cria uma solicitação pendente. Quem aprova é uma pessoa da operação, em outro sistema, e a aprovação fica registrada.
• O servidor usa uma credencial própria somente leitura para consultar o ERP, e uma credencial separada, mais restrita, para criar a solicitação.
• Cada chamada gera um log com usuário, cliente, ferramenta e resultado. Se o agente começar a se comportar de forma estranha, a equipe desliga a ferramenta de reembolso sem derrubar as consultas.

O ponto do cenário não é a tecnologia, e sim a separação: quem entra, o que pode pedir, o que o servidor decide sozinho e o que depende de uma pessoa. Para o lado do canal, Como integrar IA no WhatsApp da sua empresa trata das decisões de operação que ficam fora do servidor MCP.

Como aplicar isso em um piloto: mapear, limitar, pilotar, transferir

O método que usamos para agentes e integrações segue quatro movimentos, e eles se encaixam bem na autenticação de um servidor MCP.

• Mapear: listar quais ferramentas o servidor vai expor, quais dados cada uma toca e quem hoje tem permissão para fazer aquilo manualmente. A matriz de permissões humanas é o ponto de partida dos escopos.
• Limitar: começar com ferramentas de leitura, escopos estreitos, tokens curtos e credenciais próprias por sistema. Ações de escrita entram depois, com aprovação humana.
• Pilotar: liberar um fluxo real para poucos usuários, com logs de autorização ativos e um critério combinado de sucesso, que inclui negações legítimas e tentativas indevidas bloqueadas.
• Transferir: entregar à equipe interna o procedimento de revogação, a rotação de segredos e a revisão periódica de escopos, e decidir se o servidor expande, ajusta ou para.

Se o servidor não é seu, e sim de terceiros, a ordem muda: primeiro auditar. O roteiro em Como auditar um servidor MCP antes de instalar na empresa vale antes de qualquer configuração de login.

Checklist antes de liberar para produção

• O servidor roda somente em HTTPS e aceita o token apenas no cabeçalho Authorization.
• Há um provedor de identidade único, com autenticação em dois fatores para quem aprova clientes.
• Cada cliente aprovado está registrado com redirect URIs exatas.
• O servidor valida emissor, destinatário, expiração e escopo em toda chamada.
• Não existe repasse de token a APIs internas ou de terceiros.
• Cada ferramenta declara o escopo que exige, e as ações de escrita têm aprovação humana.
• O servidor confere permissão por dado, não só por escopo.
• Existe um procedimento escrito de revogação, com responsável e prazo.
• Os logs registram decisões de autorização sem guardar tokens nem dados pessoais além do necessário.
• Alguém foi designado para revisar escopos e clientes registrados em intervalos definidos.

Perguntas frequentes

O MCP exige OAuth? Não. A especificação trata a autorização como opcional, e servidores locais por stdio costumam usar credenciais do ambiente. Para servidores HTTP que acessam dados da empresa, a recomendação prática é implementar o fluxo descrito na especificação, porque ele traz descoberta padronizada, vínculo do token ao servidor e revogação pelo provedor de identidade.

Posso usar uma chave de API fixa em vez de OAuth? Pode, em casos pequenos e internos, mas você perde identidade por usuário, escopos finos e revogação individual. Se escolher essa rota, trate a chave como segredo com dono, escopo mínimo e rotação, e registre no log qual cliente a usou. Quando mais de uma pessoa ou agente passar a usar o servidor, migrar para OAuth costuma compensar.

Quem deve emitir os tokens, o servidor MCP ou o provedor de identidade? O provedor de identidade. A especificação separa o papel de servidor de autorização do de servidor MCP, e em empresas isso evita manter um segundo sistema de login. O servidor MCP fica responsável por validar tokens e aplicar as permissões de cada ferramenta.

Como configurar o cliente depois que o servidor está autenticado? Cada cliente tem o seu modo de registrar o servidor e de guardar credenciais. No Claude Code, por exemplo, a escolha do escopo da configuração (local, projeto ou usuário) afeta quem herda o acesso, e o artigo Configurar MCP no Claude Code: escopos local, projeto e usuário detalha essa decisão.

Fontes

• Model Context Protocol: introdução
• Google: autorização OAuth 2.0
• OWASP: Authorization Cheat Sheet
• OWASP Top 10 para aplicações com LLM