Guia de Autenticação MCP no Claude Code 2026

O que é MCP?

MCP (Model Context Protocol) é um padrão aberto desenvolvido pela Anthropic que permite ao Claude Code comunicar-se com sistemas externos de forma estruturada.
Em vez de "enfiar" a lógica da ferramenta no prompt, o MCP cria uma camada de middleware clara. Claude chama a ferramenta em um formato padrão. O servidor MCP recebe a solicitação e a encaminha para o sistema real por trás dela, como um banco de dados, API interna, serviço de nuvem ou sistema de gerenciamento de tickets.

Você pode pensar no servidor MCP como uma camada adaptadora. Um lado é o Claude Code. O outro lado é a sua infraestrutura física. Ele ajuda ambos os lados a se entenderem sem ter que reescrever tudo do zero toda vez que uma integração ocorre.

Sem o MCP, o Claude Code apenas respondia a texto. Com o MCP, ele começa a interagir com o sistema real. E a partir desse ponto, não é mais apenas "IA respondendo por diversão".

Por que a autenticação MCP é importante

À medida que o MCP se torna mais popular, vejo muitas pessoas usando o Claude Code para se conectar diretamente a sistemas internos. Alguns apenas chamam testes de API. Outros se conectam diretamente a serviços rodando na AWS com IAM rigoroso.

O problema é: assim que Claude pode chamar a ferramenta, ele representa algum tipo de identidade dentro do seu sistema.

Se a configuração de autenticação for frouxa, o risco não aparecerá imediatamente. É insidioso. Como quando depurei uma configuração do CloudFront em. Era apenas uma regra de encaminhamento de cabeçalho aparentemente inofensiva. Sem erros 500, sem tempo de inatividade. Mas, na realidade, o limite de acesso foi expandido mais do que o esperado. É preciso examinar cuidadosamente os logs para encontrar o problema.

O mesmo se aplica ao MCP. Se você escolher o método de autenticação errado, poderá, inadvertidamente:

• Expor sua chave de API de longo prazo
• Distribuir chaves de acesso para vários usuários diferentes
• Conceder ao Claude privilégios demais do que o necessário.

Conectar-se a um banco de dados de manufatura ou sistema financeiro na AWS não será mais um problema menor

Portanto, escolher o método de autenticação certo não é apenas sobre "fazer a conexão funcionar". Pode determinar a segurança e a consistência de todo o sistema por trás dela.

Por que a autenticação é a primeira coisa a considerar?

Essas ferramentas externas estão longe de ser "inofensivas". Elas podem conter código-fonte, registros de clientes, dados de produção e tickets internos. Mas quando Claude se conecta via MCP, ele não está apenas lendo por diversão. Ele está agindo como uma identidade verificada profundamente dentro do seu sistema. Se a autenticação for fraca, você poderá ser atacado. Nenhum ataque complexo é necessário. Uma chave de API vazada é tudo o que é preciso para que as coisas desandem muito rapidamente.

A situação que encontrei foi semelhante. O serviço fornece apenas um único token para os ambientes de desenvolvimento e produção. Tudo estaria bem se essa informação do token não tivesse vazado durante o teste de um repositório. Portanto, precisamos alterar as credenciais de login para os ambientes de produção e desenvolvimento para evitar problemas assim que forem descobertos. Assim, o sistema em si não é o problema; a questão crucial reside em como você gerencia as permissões. A autorização não é apenas um complemento; ela determina o que Claude pode fazer dentro de seu escopo permitido, prevenindo riscos de segurança.

O que este artigo aborda?

O Claude Code suporta vários métodos de autenticação diferentes. Por exemplo:

• Chave de API
• Token Bearer
• OAuth
• Credencial AWS (Chave de Acesso ou assumir função)

É confuso à primeira vista. Cada método existe por uma razão própria. Não existe uma "maneira certa para todos os casos".

Escolher o método errado pode levar a:

• Exposição de credenciais
• Necessidade de reconfigurar no meio do processo
• Equipe perdendo tempo corrigindo fluxos de trabalho

Certa vez, configurei um servidor MCP rodando atrás de um API Gateway na AWS.

Inicialmente, usei chaves de acesso de longo prazo para acelerar o acesso. No entanto, percebi que isso não era o ideal em comparação com o compartilhamento de chaves com vários testadores para facilitar o acesso. Por fim, mudei para suposições baseadas em função para definir as permissões de forma mais clara.

Este artigo aprofundará cada ponto, explicando quando usar cada método diferente. O objetivo é ajudá-lo a fazer a escolha certa desde o início, evitando modificações futuras.

Instalando o Claude Code

Se você ainda não instalou o Claude Code, pode configurá-lo rapidamente.

macOS, Linux, WSL:

curl -fsSL https://claude.ai/install.sh | bash

Windows PowerShell:

irm https://claude.ai/install.ps1 | iex

Apenas macOS

brew install --cask claude-code

Agora, passe para as próximas seções sobre a segurança da autenticação

Definindo Segurança em um Ambiente CLI

Ao executar uma CLI em uma máquina local, muitas pessoas pensam apenas em HTTPS. Na verdade, o maior problema reside em como você mantém suas credenciais.

HTTPS protege os dados apenas durante a transmissão. Não ajuda se o token for exposto na sua máquina. Em um ambiente CLI, os principais problemas são:

• Onde você armazena a chave?
• Quanto tempo dura o token?
• Quem pode usá-lo?

Baixa segurança é quando você deixa uma chave de API de longo prazo em um arquivo de configuração de texto simples. Se esse arquivo for acidentalmente enviado para o repositório, acabou. Essa chave está essencialmente fora de controle. E como é uma chave de longo prazo, você precisa rotacioná-la manualmente.

Certa vez, encontrei uma situação semelhante ao depurar um problema de ambiente com o ECS. Eu estava usando o Servidor MCP do Amazon ECS com uma chave de acesso e uma chave secreta. Depois disso, esqueci dessas credenciais. Alguns dias depois, pedi a Claude para investigar alguns problemas em outro ambiente, mas ele ainda estava usando as credenciais antigas, então acabou realizando muitas ações no ambiente de produção.

Alta segurança é diferente. Você usa tokens de curto prazo. Ou referenciando via variáveis de ambiente. Ou usando mecanismos de autenticação em nível de serviço, como funções IAM. Por exemplo, ao usar o AWS SSO, os tokens têm uma data de expiração clara. Após a expiração, você precisa fazer login novamente. Se a máquina for comprometida, o invasor tem apenas uma janela muito curta para fazer algo. Este método não é perfeito. Mas minimiza os danos se algo der errado.

Abaixo estão quatro métodos comuns de configuração de autenticação para servidores MCP no Claude Code. Cada método é adequado para um contexto diferente.

1. Cabeçalhos HTTP Estáticos (Chaves de API e Tokens de Portador)

Este é o método mais fácil para começar. Essa abordagem funcionará bem com muitos serviços de terceiros que usam chaves de API de longo prazo ou Tokens de Acesso Privado (PATs).

Configuração da Linha de Comando

Se você quiser adicionar rapidamente um servidor MCP com um cabeçalho de autenticação, basta usar “claude mcp add” e passar “--cabeçalho”

# Add a weather service MCP server with Bearer Token authentication
claude mcp add weather-service \
    --transport http \
    --header "Authorization: Bearer secret-token-123" \
    https://api.weather-data.com/mcp

Quando o processo estiver concluído, Claude escreverá automaticamente a configuração para você. Nenhuma etapa manual é necessária. “Claude/settings.json”. Este método é muito conveniente para verificar rapidamente um serviço externo.

Costumo usá-lo quando preciso testar uma API antes de integrá-la oficialmente ao sistema. Apenas lembre-se de uma coisa: Não cole o token real no comando e depois salve o histórico do shell em algum lugar. Isso acontece com mais frequência do que você imagina.

Arquivo de Configuração (.claude/settings.json)

Se não quiser colocar o código do token no arquivo como texto simples, você pode usar uma variável de ambiente.

Claude lerá “${ENV_VAR}” e o substituirá pelo valor real quando a CLI for iniciada.

Por exemplo:

{
  "mcpServers": {
    "data-tool": {
      "url": "https://api.myservice.com/mcp",
      "type": "http",
      "headers": {
        "Authorization": "Bearer ${APP_API_TOKEN}",
        "X-Org-Id": "org-888"
      }
    }
  }
}

Este método é mais seguro do que escrever o token diretamente no arquivo. Você só precisa exportar a variável de ambiente antes de executar o Claude.

Certa vez, vi um repositório interno fazer commit acidentalmente de um token na configuração. Inicialmente, pensei que era um repositório privado, então estava tudo bem. Então o repositório foi compartilhado com outra equipe para testes. O token de produção também estava incluído. Usar variáveis de ambiente não resolve todos os riscos. Mas pelo menos reduz a chance de exposição da chave ao fazer commit por engano.

Vantagens:

• Fácil de configurar.
• Adequado para integração rápida com serviços externos.

Desvantagens:

• O token ainda é do tipo de longo prazo.
• Se exposto, você terá que rotacioná-lo manualmente.

2.1 Credenciais AWS MCP

2.1 Chave de Acesso e Chave Secreta (para Servidores MCP hospedados na AWS)

Se o seu servidor MCP estiver localizado na AWS, isso é muito mais prático. Você pode usar as credenciais de login AWS existentes na sua máquina. Normalmente, isso é configurado via AWS configure ou AWS SSO. Claude herdará variáveis como:

• AWS_ACCESS_KEY_ID
• AWS_SECRET_ACCESS_KEY
• AWS_SESSION_TOKEN
• AWS_PROFILE

Isso é muito útil quando o servidor MCP é executado por trás de um API Gateway. Ou quando o backend está no Lambda ou ECS e a autenticação IAM está ativada. 

Por exemplo, configurar um proxy MCP para assinar requisições usando Signature V4:

{
  "mcpServers": {
    "cloud-logger": {
      "command": "node",
      "args": ["/path/to/aws-mcp-proxy.js"],
      "env": {
        "AWS_PROFILE": "my-dev-profile",
        "AWS_REGION": "ap-southeast-1",
        "MCP_ENDPOINT": "https://my-mcp-service.execute-api.ap-southeast-1.amazonaws.com/prod"
      }
    }
  }
}

Ou, mais simplesmente, exportar variáveis de ambiente antes de executar Claude:

# Definir credenciais AWS antes de executar o Código Claude

export AWS_PROFILE=my-dev-profile
export AWS_REGION=ap-southeast-1

# Iniciar Código Claude — o servidor MCP usará estas credenciais claude

Claude não precisa conhecer os detalhes da chave. Ele apenas usa o contexto AWS no qual você está logado.

Lembro-me de depurar um servidor MCP interno executado por trás de um API Gateway. As requisições estavam consistentemente retornando erros 403. Na época, pensei que fosse um problema de política. Mas então descobri que o certificado AWS SSO na minha máquina havia expirado. Simplesmente executar o “aws sso login” comando novamente resolveu tudo. Desde então, sempre observei que serviços registrados precisam verificar a sessão antes de trabalhar neles, em vez de culpar o IAM.

Vantagens:

• Tokens são geralmente de curto prazo via STS.
• Podem ser automaticamente rotacionados.
• Maior segurança do que chaves de API de longo prazo.

Desvantagens:

• Dependente do status de login da AWS.
• Tudo para imediatamente assim que a sessão termina.

2.2. Assunção de Função IAM (Princípio do Menor Privilégio)

Quando você usa credenciais AWS diretamente, Claude está agindo sob sua identidade pessoal. Isso é conveniente, mas nem sempre é a maneira correta. Assumir uma Função permite que o MCP use uma identidade separada. Esta identidade serve apenas a uma máquina ou serviço específico. Isso é muito útil quando você quer simular a produção.

Por exemplo, testar como um serviço funciona com acesso somente leitura. Ou quando o servidor MCP aceita apenas uma Função IAM fixa. Ele não permite que usuários individuais o chamem diretamente.

Encontrei um caso como este. Uma API interna permitia acesso apenas a funções de backend. Usuários individuais eram bloqueados. Para testar localmente, você tinha que assumir aquela função específica.

O fluxo de trabalho é bem claro:

1. Você solicita assumir uma Função IAM.
2. O AWS STS verifica se você tem permissão para usar sts:AssumeRole. Se for válido, o STS retorna uma credencial temporária.
3. O proxy MCP usará essa credencial temporária para chamar o serviço de destino. O serviço vê apenas a função, não o seu usuário individual.

O que eu gosto neste método são as permissões muito claras. As funções têm suas próprias políticas. Se você quiser impor quaisquer restrições, pode ajustá-las nessa política. A desvantagem é que a configuração inicial é um pouco demorada. Se a política de confiança estiver errada em apenas uma linha, a assunção não funcionará. E depurar IAM nunca é uma tarefa divertida.

Exemplo de Configuração

{
  "mcpServers": {
    "finance-bot": {
      "command": "node",
      "args": ["/path/to/aws-role-mcp-proxy.js"],
      "env": {
        "ASSUME_ROLE_ARN": "arn:aws:iam::123456789012:role/mcp-finance-bot-role",
        "AWS_REGION": "ap-southeast-1",
        "MCP_ENDPOINT": "https://secure-finance.execute-api.ap-southeast-1.amazonaws.com/prod"
      }
    }
  }
}

Configurando permissões IAM para assumir funções

Para assumir uma função, seu usuário atual deve ter essa permissão. Sem a política de confiança correta, tudo parará imediatamente.

Geralmente, definirei algumas variáveis para simplificar:

# Definir variáveis

export ACCOUNT_ID="123456789012"
export ROLE_NAME="mcp-finance-bot-role"
export MY_USER_ARN="arn:aws:iam::${ACCOUNT_ID}:user/developer@company.com"

# Atualizar a política de confiança da função para permitir que seu usuário a assuma

aws iam update-assume-role-policy \
    --role-name "${ROLE_NAME}" \
    --policy-document '{
      "Version": "2012-10-17",
      "Statement": [{
        "Effect": "Allow",
        "Principal": {"AWS": "'"${MY_USER_ARN}"'"},
        "Action": "sts:AssumeRole"
      }]
    }

Esta seção essencialmente faz apenas uma coisa. Ela informa à AWS que seu usuário tem permissão para assumir essa função.

Certa vez, perdi quase uma tarde inteira só porque me faltava o ARN correto na política de confiança. A política anexada à função estava correta. Mas a política de confiança não permitia que o usuário assumisse. Como resultado, o STS continuava retornando um erro de AccessDenied. Outro ponto a lembrar:

O IAM tem um pequeno atraso. Após atualizar a política, você pode ter que esperar um minuto ou dois para que ela entre em vigor. Se o teste imediato ainda falhar, não entre em pânico.

Vantagens:

• Mantém o princípio de privilégio mínimo.
• Tudo o que uma função pode fazer está dentro de sua política.

Desvantagens:

• A configuração é um pouco complicada.
• Apenas um pequeno erro e não funcionará.

3. Suporte OAuth 2.0 Integrado

Para serviços de terceiros complexos como GitHub, Linear ou Slack, uma chave de API não é suficiente. Eles exigem login através de um fluxo de usuário padrão. O Claude Code oferece suporte OAuth integrado para esses tipos de servidores MCP.

Comandos Shell

Você não precisa escrever seu próprio fluxo de login. Antes de começar, você pode verificar quais servidores exigem autenticação:

# List the MCP servers that need authentication
claude mcp list

Se você vir algum servidor que não esteja logado, basta executar:

# Start the login flow for a GitLab MCP server (opens browser)
claude mcp auth gitlab-server

Comandos Interativos

Há um recurso conveniente. Se você estiver usando o Claude e encontrar um erro de permissão, não precisa sair. Você pode autorizar diretamente dentro da sessão de chat. 

Exemplo: 

>>> Você: Liste minhas tarefas.

>>> Claude: Preciso de acesso ao Linear.

>>> /mcp auth linear-server

Basta digitar esse comando. Claude reativará o fluxo de login. Geralmente, ele abrirá o navegador para você confirmar as permissões.

Certa vez, deparei-me com uma situação em que o token do Linear expirou enquanto eu revisava um problema. Claude relatou permissões insuficientes no meio do processo.

 Em vez de reiniciar a CLI, eu apenas executei “/mcp auth” e pronto. Voltei ao trabalho imediatamente depois.

Vantagens:

• Fluxo OAuth padrão.
• Tokens são atualizados automaticamente.
• Uma experiência bastante fluida ao trabalhar com um usuário.

Desvantagens:

• Ocasionalmente, você ainda precisa abrir o navegador e fazer login novamente. Especialmente ao trocar de computador ou quando a sessão de login termina.

Resumo

A escolha do método de autenticação depende de duas coisas:

• Onde você armazena suas credenciais.
• E qual problema você está resolvendo.

Não existe uma opção “melhor para todos os lugares”. Apenas aquela que se encaixa no contexto. Uma observação pequena, mas importante: certifique-se de que seu ambiente Node.js esteja estável primeiro. Finalmente descobri que a máquina local estava usando a versão errada do Node. Simplesmente alterá-lo para “nvm use" deve funcionar normalmente. Usar o nvm ajuda a evitar muitos erros inexplicáveis devido a incompatibilidades de ambiente. Não subestime isso. 

Guia Rápido: Adicionando Servidores MCP no Código Claude

Transporte HTTP com Cabeçalho de Autenticação

# Transporte HTTP com cabeçalho de autenticação

claude mcp add my-server \
    --transport http \
    --header "Authorization: Bearer ${MY_TOKEN}" \
    https://my-mcp-server.com/mcp

# Transporte Stdio (processo local)

claude mcp add my-local-server \
    -- node /path/to/server.js

# Listar servidores MCP configurados

claude mcp list

# Remover um servidor MCP

claude mcp remove my-server

Basta lembrar estes comandos para começar. O restante consiste em escolher o método de autenticação adequado para cada situação.

Perguntas Frequentes

Como gerar um token OAuth do Claude Code MCP?

Para gerar um token OAuth do Claude Code MCP, você geralmente se integra a um provedor OAuth que emite tokens de acesso de curta duração. Este método altamente seguro ajuda a evitar a exposição direta de credenciais de longo prazo para suas conexões Claude Code MCP. As etapas específicas dependem da configuração do provedor OAuth escolhido e de sua integração com o Claude Code.

O Claude Code pode acessar servidores MCP?

Sim, o Claude Code pode acessar servidores MCP, permitindo a interação com sistemas externos como bancos de dados e APIs. Essa funcionalidade transforma o Claude Code de um respondedor de texto em um participante ativo do sistema. Uma autenticação eficaz do Claude Code MCP é vital para operações seguras, prevenindo acesso não autorizado e garantindo a integridade dos dados em toda a infraestrutura dos EUA.

Como autenticar o Figma MCP no Claude Code?

Para autenticar o Figma MCP no Claude Code, você precisará escolher um método de autenticação seguro para o Claude MCP. Isso geralmente envolve o uso de chaves de API, OAuth ou tokens Bearer, dependendo da integração do Figma e de suas políticas de segurança. Concentre-se em conceder privilégios mínimos e evitar chaves de longo prazo para garantir uma interação segura com o sistema.