Autenticação em Servidores MCP: OAuth, Tokens e Confiança
Autenticar um servidor MCP vai muito além de colocar uma senha. Entenda como OAuth, público do token, escopos e verificações por ferramenta se combinam em servidores HTTP — e o que fazer em servidores locais stdio.
Nesta página
Autenticação em Servidores MCP: OAuth, Tokens e Confiança
Um assistente de IA pode resumir uma página pública sem perguntar quem é você. Mas, se vai consultar uma agenda privada ou alterar um cadastro de cliente, “o modelo pediu” não é uma verificação de segurança. O servidor precisa saber quem está chamando, em nome de quem a solicitação é feita e o que essa identidade pode fazer.
Esse é o papel da autenticação e da autorização em um servidor MCP. Vamos desembaraçar as siglas e acompanhar o que acontece quando uma conexão MCP remota exige login.
Duas perguntas, duas respostas
Autenticação responde: “Quem ou o que está fazendo esta solicitação?” Autorização responde: “O que essa identidade pode fazer aqui?” Um login válido não concede automaticamente acesso a todas as ferramentas e dados.
O MCP não exige que todo servidor use OAuth. Um serviço público e somente de leitura talvez não precise de login. Já um servidor HTTP remoto que acessa dados privados ou executa ações importantes precisa de um projeto cuidadoso de identidade e permissões. A especificação atual de autorização do MCP descreve o uso de OAuth em transportes HTTP; servidores locais via stdio seguem outro modelo.
Quem participa de um login MCP remoto?
Pense no cliente MCP como o conector dentro de um host de IA, no servidor MCP como o serviço protegido e no servidor de autorização como o provedor de identidade que autentica a pessoa e emite tokens. No vocabulário OAuth, o servidor MCP é o servidor de recursos: ele recebe e valida tokens de acesso. Ele não deve se passar pelo provedor de login.
Uma conexão HTTP protegida costuma seguir este caminho:
- O cliente tenta se conectar. Se precisar de autorização, o servidor responde com HTTP 401 e um desafio
WWW-Authenticateque aponta para os metadados do recurso protegido. - O cliente descobre qual servidor de autorização pode emitir credenciais para aquele recurso. A descoberta evita que um servidor não confiável invente uma URL de login arbitrária.
- O cliente inicia um fluxo OAuth. No caso interativo comum, a pessoa entra no provedor de identidade e aprova o acesso solicitado. O fluxo deve corresponder ao tipo do cliente, incluindo PKCE para clientes públicos.
- O servidor de autorização emite um token de acesso para o recurso MCP pretendido, com as permissões aprovadas.
- O cliente repete a solicitação MCP com
Authorization: Bearer <token-de-acesso>. O servidor MCP valida o token antes de processá-la.
As opções exatas de cadastro e descoberta do cliente dependem do ecossistema OAuth implantado. Siga a especificação atual de autorização do MCP e as orientações do provedor de identidade; evite copiar sem revisão um exemplo antigo de “OAuth para MCP”.
O destino do token importa
Um token bearer é como um ingresso: quem o possui pode usá-lo dentro dos limites definidos. Um token destinado a uma API não pode virar um passe universal. O servidor de autorização deve vincular o token ao recurso/público do servidor MCP, e o MCP deve rejeitar tokens cujo público, emissor, assinatura, validade ou outras declarações não correspondam à política esperada.
Depois, confira as permissões no momento de cada uso. Um token pode permitir calendar:read, mas não calendar:write; uma pessoa pode acessar uma área de trabalho e não outra. Mantenha os escopos restritos e ainda aplique regras por pessoa, organização e registro dentro de cada ferramenta. O portão do token deixa a pessoa entrar no prédio; ele não decide que todos os cômodos são dela.
Login não significa “confiar no modelo”
Mesmo depois do login, ferramentas continuam sendo capacidades reais. Uma ferramenta que envia e-mails, exclui arquivos, transfere dinheiro ou altera configurações de produção exige validação de entradas e, quando apropriado, uma etapa explícita de aprovação. O modelo pode sugerir uma chamada; seu servidor deve validar os argumentos, aplicar as permissões reais da pessoa e explicar ações importantes.
Observe os problemas destacados nas orientações de segurança do MCP: agente confuso, encaminhamento inseguro de tokens, falsificação de solicitações do lado do servidor (SSRF), URLs de autorização maliciosas, escopos amplos demais e processos locais que podem ser substituídos ou imitados. Trate descrições e resultados de ferramentas como entradas não confiáveis. Autenticação é uma camada, não um campo de força para ferramentas mal projetadas.
E um servidor local via stdio?
Um servidor MCP local iniciado por entrada e saída padrão não usa o fluxo de descoberta OAuth por HTTP. A especificação de autorização do MCP recomenda que implementações stdio obtenham credenciais do ambiente em vez de implementar aquele mecanismo HTTP. Na prática, use o armazenamento de segredos ou credenciais documentado pelo host quando disponível, limite as permissões do processo local e nunca imprima segredos em logs ou na saída do protocolo.
Tenha cuidado com variáveis de ambiente herdadas: elas podem vazar por diagnósticos, relatórios de falha, processos filhos ou contas de máquina permissivas. Um servidor local continua sendo código executável com acesso ao computador da pessoa; instale-o e atualize-o somente de fontes confiáveis.
Checklist prático
| Verificação | O que uma configuração segura faz |
|---|---|
| Transporte | Usa HTTPS em conexões HTTP remotas |
| Descoberta | Usa metadados de recurso protegido MCP e um servidor de autorização confiável |
| Token | Verifica assinatura, emissor, validade e recurso/público pretendido |
| Permissões | Solicita escopos mínimos e valida o acesso dentro de cada ferramenta |
| APIs downstream | Usa credenciais destinadas àquela API; nunca encaminha um bearer token alheio |
| Efeitos colaterais | Valida entradas e pede aprovação clara para ações sensíveis |
| Operação | Não registra tokens em logs, troca credenciais e monitora falhas de autenticação |
stdio local | Usa o mecanismo de credenciais aceito pelo host e restringe o processo |
Ao construir um servidor, prefira o suporte de autorização do SDK MCP e um provedor de identidade mantido, em vez de implementar leitura de tokens à mão. Teste as falhas com o mesmo cuidado do login bem-sucedido: público errado, token expirado, escopo ausente, conta revogada e tentativa de acessar os dados de outra pessoa.
Em resumo
A autenticação MCP é uma negociação entre cliente, recurso protegido e servidor de autorização. OAuth pode estabelecer quem aprovou o acesso e emitir um token, mas o servidor MCP ainda precisa validar esse token, limitar o alcance e autorizar cada ação. Mantendo essas verificações separadas, o login vira um limite de segurança útil — e não um botão mágico de “confie nesta IA”.
Para saber mais
Read next
Como Gerar Áudio a Partir de Texto com Texto para Fala (TTS)
Transforme um roteiro escrito em áudio falado: experimente a voz integrada do navegador e depois gere um MP3 com uma API moderna de texto para fala. Aprenda a escolher vozes, ajustar a pronúncia com SSML e revisar a qualidade.
nbkhope
Como Rotular Dados para IA: Um Guia Prático para Bons Exemplos de Treinamento
Aprenda a rotular dados para IA com uma tarefa clara, regras práticas, um pequeno piloto e verificações de qualidade que revelam divergências em vez de escondê-las. Inclui um exemplo de atendimento ao cliente.
nbkhope
Crie Seu Próprio Servidor MCP: Dê um Novo Superpoder à IA
Crie um servidor MCP de verdade: ofereça uma ferramenta útil, conecte-a a um app de IA, acompanhe a conversa e conheça os cuidados de segurança que transformam uma demo em uma boa integração.
nbkhope
Comentários
Be kind and specific. Comments with links from new accounts appear after a moderator reviews them.