Autenticação e Autorização MCP: OAuth 2.1, Delegação de Tokens e o Problema do Deputado Confuso

A autenticação é o guardião que determina se as poderosas capacidades de um servidor MCP estão disponíveis para usuários legítimos ou para atacantes. Se você errar nisso, todos os outros controles de segurança se tornam irrelevantes — um servidor MCP não autenticado ou mal autenticado com acesso a e-mail, arquivos e bancos de dados é uma vulnerabilidade crítica, independentemente de quão bem você tenha fortalecido todo o resto.

O guia do Projeto de Segurança OWASP GenAI identifica autenticação e autorização como um dos oito domínios principais de segurança para servidores MCP, com requisitos específicos que vão além do que a maioria dos desenvolvedores implementa por padrão. Este post explica por que esses requisitos existem e como implementá-los corretamente.

O Desafio da Autenticação no MCP

Os servidores MCP enfrentam um cenário de autenticação mais complexo do que os serviços tradicionais porque medeiam entre múltiplos principais:

• O usuário cujas instruções conduzem o assistente de IA
• O modelo de IA que interpreta instruções e chama ferramentas
• O cliente MCP (a aplicação que hospeda a IA)
• O servidor MCP que executa chamadas de ferramentas
• Serviços downstream que o servidor MCP chama em nome do usuário

Cada uma dessas relações requer seus próprios controles de autenticação e autorização. Uma fraqueza em qualquer elo pode ser explorada para contornar os outros.

Obrigatório: OAuth 2.1 e OIDC para Servidores Remotos

Para servidores MCP remotos — aqueles acessados pela rede em vez de através de STDIO local ou sockets Unix — o guia OWASP GenAI é inequívoco: OAuth 2.1 com OIDC é obrigatório, não opcional.

Este requisito existe porque:

OAuth 2.1 fornece controle de escopo explícito. Cada token de acesso declara exatamente quais recursos e ações ele autoriza. Um servidor MCP pode verificar no momento da invocação da ferramenta que o token apresentado tem o escopo específico necessário para essa ação — não apenas que o usuário está autenticado, mas que está autorizado para esta operação específica.

OIDC fornece identidade criptográfica. OpenID Connect adiciona asserções de identidade (o token de ID) que o servidor MCP pode verificar sem fazer uma ida e volta ao provedor de identidade. O servidor valida o iss (emissor), aud (audiência), exp (expiração) e assinatura em cada solicitação.

Tokens OAuth 2.1 são de curta duração por design. A especificação OAuth moderna (que consolida e substitui as melhores práticas do OAuth 2.0) enfatiza tokens de acesso de curta duração que devem ser regularmente renovados. Isso limita a janela de dano se um token for comprometido.

O Que Validar em Cada Solicitação

Não valide tokens apenas no estabelecimento da sessão. Valide em cada invocação de ferramenta:

def validate_token(token: str, required_scope: str) -> TokenClaims:
    claims = jwt.decode(
        token,
        key=get_public_key(claims_preview['kid']),
        algorithms=["RS256", "ES256"]
    )

    assert claims['iss'] == EXPECTED_ISSUER
    assert EXPECTED_AUDIENCE in claims['aud']
    assert claims['exp'] > time.time()
    assert required_scope in claims['scope'].split()

    return claims

Nunca armazene em cache os resultados de validação entre solicitações. Um token que era válido no início da sessão pode ser revogado no meio da sessão.

Ambientes de Cliente Dinâmicos

Em ambientes onde os clientes MCP mudam frequentemente (por exemplo, diferentes assistentes de IA se conectando ao mesmo servidor), chaves de API estáticas ou segredos pré-compartilhados são insuficientes. Use registro de cliente dinâmico com OAuth 2.1 ou OIDC para verificar a identidade do cliente no momento da conexão. Listas de permissões, políticas de conexão codificadas ou TLS mútuo (mTLS) são apropriados para relacionamentos estáticos conhecidos entre clientes e servidores específicos.

Pronto para expandir seu negócio?

Comece seu teste gratuito hoje e veja resultados em dias.

Solicitar demo Entrar

O Problema do Deputado Confuso

Entendendo o Ataque

O Deputado Confuso é uma vulnerabilidade clássica de autorização com uma manifestação particularmente perigosa em arquiteturas MCP. O ataque explora a ambiguidade de com qual autoridade um servidor MCP está agindo.

Considere este cenário:

• A usuária Alice está autenticada em um servidor MCP com permissões limitadas — ela pode ler seus próprios arquivos, mas não os de outros
• O servidor MCP tem amplas permissões de conta de serviço para ler todos os arquivos da organização
• O servidor MCP usa passagem de token: ele encaminha o token de Alice para serviços downstream

Quando Alice pede ao assistente de IA para “resumir minha pasta de projeto”, o servidor usa o token de Alice para acessar seus arquivos — comportamento correto. Mas se um atacante engana o servidor para fazer uma solicitação usando suas próprias credenciais de serviço (talvez através de um ataque de envenenamento de ferramenta ou injeção de prompt indireta), as permissões elevadas do servidor são usadas para acessar arquivos que Alice não está autorizada a ver.

O servidor é o “deputado confuso” — ele foi enganado para usar sua autoridade em nome de alguém que não tem essa autoridade, agindo como um proxy para escalação de privilégios.

Por Que a Passagem de Token Cria Esta Vulnerabilidade

Muitas implementações MCP encaminham o token do cliente para APIs downstream por simplicidade. Isso parece intuitivo — o token do usuário representa as permissões do usuário, então usá-lo para todas as chamadas downstream mantém o controle de acesso correto.

O problema: APIs downstream que reconhecem o servidor MCP como um intermediário confiável podem conceder solicitações usando o nível de identidade do servidor, não o nível do token de usuário encaminhado. E se o servidor MCP agir por iniciativa própria — através de tomada de decisão de IA que o usuário não solicitou explicitamente — ele pode usar suas próprias credenciais em vez do token do usuário.

Encaminhar tokens de usuário também:

• Quebra trilhas de auditoria (logs downstream mostram identidade do usuário, não identidade do servidor, obscurecendo a camada MCP)
• Dá a um atacante que compromete o servidor MCP acesso a todos os tokens de usuário encaminhados
• Cria problemas de conformidade se tokens de diferentes usuários podem ser confundidos ou reproduzidos

A Solução: Delegação Explícita de Token com Fluxos On-Behalf-Of

Em vez de encaminhar tokens de cliente, o servidor MCP deve obter seus próprios tokens para acesso a serviços downstream usando o fluxo On-Behalf-Of (OBO) do OAuth:

Usuário autentica no cliente MCP → cliente obtém token de acesso do usuário
Cliente MCP apresenta token do usuário ao servidor MCP
Servidor MCP troca token do usuário por um token do servidor via fluxo OBO:
  POST /token
  grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
  assertion=<user_access_token>
  scope=<minimum_required_scope>
Servidor MCP usa seu próprio token OBO para chamadas downstream

O token OBO:

• É explicitamente delimitado às permissões mínimas necessárias para a chamada de ferramenta específica
• Identifica o servidor MCP como a parte chamadora (com o usuário como sujeito)
• Está vinculado ao evento de autenticação do usuário (pode ser revogado quando a sessão do usuário termina)
• Não expõe o token completo do usuário a serviços downstream

Tokens de Curta Duração e com Escopo Definido

O guia OWASP GenAI faz uma recomendação específica: emita tokens de acesso com tempos de vida medidos em minutos, não horas. Isso se aplica tanto aos tokens que o servidor MCP aceita de clientes quanto aos tokens que ele obtém para acesso a serviços downstream.

Por Que Tempos de Vida Curtos Importam

Um token de acesso roubado é válido por todo o seu tempo de vida, independentemente de o usuário legítimo ter feito logout, alterado sua senha ou revogado sua sessão. Um token de 24 horas roubado no início de uma sessão dá a um atacante 24 horas de acesso persistente. Um token de 5 minutos roubado no meio da sessão dá no máximo 5 minutos.

Tokens de curta duração também impõem eventos regulares de reautenticação, que fornecem oportunidades para:

• Verificar novamente se a conta do usuário foi suspensa ou suas permissões alteradas
• Detectar padrões de autenticação anômalos (horários, locais ou frequência incomuns)
• Aplicar autenticação adicional para operações sensíveis

Minimização de Escopo de Token

Cada token deve carregar apenas os escopos necessários para a operação específica sendo executada. Não emita um token com escopo read:files write:files delete:files quando a chamada de ferramenta atual só precisa de read:files. Isso limita o dano se o token for interceptado ou o modelo for manipulado para fazer chamadas de ferramenta inesperadas.

def get_tool_token(user_id: str, tool_name: str) -> str:
    # Mapear ferramenta para escopos mínimos necessários
    required_scopes = TOOL_SCOPE_MAP[tool_name]

    return oauth_client.get_token(
        subject=user_id,
        scopes=required_scopes,
        lifetime_seconds=300  # tempo de vida de 5 minutos
    )

Junte-se à nossa newsletter

Receba gratuitamente as últimas dicas, tendências e ofertas.

Endereço de e-mail

Inscrever-se

Tratando Sessões como Estado, Não Identidade

Um erro comum é usar IDs de sessão como proxies de autorização: se uma solicitação carrega um ID de sessão válido, o servidor assume que está autorizada. Isso confunde gerenciamento de estado com verificação de identidade.

O modelo correto: IDs de sessão gerenciam estado conversacional. A autorização é verificada independentemente em cada solicitação validando as reivindicações do token OAuth. Mesmo uma solicitação carregando um ID de sessão válido deve apresentar um token OAuth válido, não expirado e com escopo adequado antes que qualquer invocação de ferramenta seja permitida.

Isso importa porque IDs de sessão podem ser roubados, adivinhados ou reproduzidos de maneiras que tokens OAuth — que carregam garantias de integridade criptográfica — não podem.

Aplicação Centralizada de Políticas

Em vez de implementar verificações de autorização espalhadas por manipuladores de ferramentas individuais, o guia OWASP GenAI recomenda um gateway de política centralizado que:

• Intercepta todas as solicitações de invocação de ferramenta antes que alcancem código específico de ferramenta
• Valida autenticação (assinatura de token, emissor, audiência, expiração)
• Aplica autorização (escopo necessário para esta ferramenta específica)
• Aplica verificação de consentimento (o usuário autorizou explicitamente este tipo de ação?)
• Implementa filtragem de ferramentas (esta ferramenta é permitida neste contexto de implantação?)
• Registra todas as decisões com contexto completo para auditoria

A centralização garante que as políticas sejam aplicadas de forma consistente em todas as ferramentas e agentes. Uma verificação de autorização específica de ferramenta pode ser esquecida ou contornada durante o desenvolvimento; uma verificação de gateway não pode.

Resumo: A Lista de Verificação de Autenticação

Para servidores MCP remotos, o padrão mínimo de segurança de autenticação é:

• OAuth 2.1 / OIDC aplicado para todas as conexões
• Assinatura de token, emissor, audiência e expiração validados em cada invocação de ferramenta
• Sem passagem de token para APIs downstream — use OBO ou tokens emitidos pelo servidor
• Tokens de acesso delimitados às permissões mínimas necessárias por ferramenta
• Tempos de vida de token medidos em minutos com renovação obrigatória
• IDs de sessão não usados como proxies de autorização
• Gateway de aplicação de política centralizado em vigor
• Todos os eventos de autenticação e decisões de autorização registrados de forma imutável

Recursos Relacionados

• Segurança do Servidor MCP: 6 Vulnerabilidades Críticas
• Lista de Verificação de Segurança MCP: O Padrão Mínimo para Implantação Segura
• Segurança de API LLM: Limitação de Taxa, Autenticação e Prevenção de Abuso
• Protegendo Agentes de IA: Prevenção de Ataques em Múltiplas Etapas
• Auditoria de Segurança de Chatbot de IA: O Que Esperar