Autenticação e Autorização MCP: Principais Diferenças Explicadas

Quando um agente de IA se conecta a um servidor MCP, o agente deve verificar sua identidade (autenticação MCP) e definir as funções que ele tem permissão para executar uma vez concedido o acesso (autorização MCP) para garantir a segurança tanto para o cliente MCP quanto para o sistema. É fundamental diferenciar entre esses dois tipos de verificações de controle de acesso.

Quando as verificações de segurança são usadas incorretamente ou de forma intercambiável, surgem lacunas de segurança que representam desafios para usuários e administradores de sistemas tradicionais. Em ambientes MCP, a falta de verificações de segurança definidas cria riscos mais sérios do que em sistemas tradicionais.

Este guia fornece descrições detalhadas da autenticação e autorização MCP, como elas funcionam dentro do ecossistema do protocolo de contexto de modelo e o que é preciso para implementar esses conceitos para uma adoção empresarial bem-sucedida em um ambiente de produção real.

O Que É Autenticação MCP?

A autenticação MCP é o primeiro ponto de verificação entre um cliente MCP e um servidor MCP. Antes de executar qualquer comando via ferramentas, o cliente deve se identificar e se autenticar para estabelecer confiança. Para autenticar em servidores MCP remotos (HTTP/HTTPS), o mecanismo de autorização mais comum usado é o OAuth 2.1 com PKCE.

Quando um agente se autentica com sucesso em um servidor de autorização, o cliente troca credenciais por um token OAuth, muitas vezes por meio de uma troca de token iniciada no endpoint de metadados. O servidor MCP não permitirá uma conexão a menos que o agente tenha um token OAuth válido.

Ao contrário dos métodos de conexão padrão, servidores MCP locais que se conectam via transporte STDIO não exigem que um agente se autentique. Em vez disso, eles usam o limite de confiança do processo host, muitas vezes configurado via variáveis de ambiente em casos de uso básicos.

Os tipos de credenciais mais comumente usados são os seguintes:

• Tokens de Acesso OAuth 2.1: De curta duração (geralmente uma hora) e com escopo limitado, este é o tipo de credencial recomendado para acesso seguro em sistemas de nível de produção.
• Chaves de API: Fácil de usar, sem expiração ou controle de acesso granular; este tipo de credencial é considerado arriscado ao gerenciar muitos usuários em sistemas externos.
• JWTs: As reivindicações sobre a identidade dos usuários, como usuário, função e locatário, são incorporadas ao JWT, embora tragam complexidade adicional devido à necessidade de lógica de autorização extra.
  

Desde a atualização de junho de 2025 da especificação MCP, os servidores agora são tratados como servidores de recursos OAuth e validam tokens, mas não emitem tokens para os usuários. Em vez disso, a responsabilidade pela emissão de tokens foi transferida para provedores de identidade externos, como Okta, Azure AD e Auth0.

Isso cria um ponto único de autenticação MCP e traz SSO, MFA e auditabilidade em nível de identidade para o ecossistema MCP sem a necessidade de implementações personalizadas.

O Que É Autorização MCP?

A autenticação estabelece a identidade do cliente, enquanto a autorização MCP determina as capacidades do cliente.

A autorização governa o controle de acesso em um nível muito detalhado, fornecendo restrições sobre quais ferramentas podem ser invocadas, quais dados podem ser acessados e sob quais condições essas ações podem ser realizadas. A autorização é avaliada continuamente, em vez de ser uma avaliação única, para cada invocação de ferramenta.

Em sistemas MCP, a autorização geralmente utiliza uma abordagem em camadas. As camadas de autorização encontradas em sistemas MCP incluem:

• Permissões baseadas em escopo: Permissões definidas na emissão do token que estabelecem os limites externos de todos os possíveis escopos OAuth e ações realizadas.
• Controle de Acesso Baseado em Função (RBAC): Mapeamento de permissões para funções para garantir que qualquer usuário e todos os agentes de IA que acessam a mesma função tenham os mesmos direitos de acesso a esses recursos.
• Controles em nível de recurso: Restrição de acesso seguro a conjuntos de dados, ferramentas ou ambientes específicos.
• Políticas Contextuais: Aplicação de condições de tempo de execução, como hora, padrões de solicitação ou sinais de risco, aos itens acima

A camada final de autorização representa o aspecto mais interessante da estrutura de autorização MCP moderna. Um token que foi autorizado a chamar o método read_file às 9h também pode ter a capacidade de chamar o mesmo método negada às 2h, com base em outra política aplicável aos dois primeiros parâmetros de referência.

Autenticação vs. Autorização em MCP: As Principais Diferenças

Embora autenticação e autorização sejam por vezes confundidas, elas representam uma abordagem de dois níveis no contexto do MCP. As duas áreas fornecem diferentes níveis de controle de acesso, e os modos de falha de cada uma diferem correspondentemente.

Se a autenticação estiver correta, mas a autorização adequada não for aplicada, cada cliente autenticado torna-se um superusuário.

Os modos de falha frequentemente se opõem:

• A autenticação MCP fraca permite a passagem de identidades incorretas.
• A autorização MCP fraca permite que identidades corretas realizem ações excessivas.

Sistemas MCP de estilo de produção exigem que ambos os tipos de controle sejam aplicados independentemente

Como a Autenticação e Autorização MCP Funcionam Juntas em um Fluxo MCP Real?

Abaixo está um exemplo real de uma sequência de etapas que ocorrem quando um agente contata um servidor MCP remoto. Isso levará a uma chamada de ferramenta bem-sucedida ou resultará em falha.

Passo 1: O agente tenta conectar-se ao servidor MCP como um cliente MCP. O servidor MCP não reconhece o cliente como tendo uma sessão aberta, portanto, ele retorna uma resposta 401 Não Autorizado juntamente com metadados do servidor de autorização apontando para o servidor de autorização.

Passo 2: O agente envia uma solicitação de redirecionamento para o servidor de autorização (seja Okta, Azure AD ou Auth0), onde o fluxo OAuth com PKCE é concluído. O usuário ou serviço autentica-se e consente com os escopos OAuth solicitados, recebendo um código de autorização.

Passo 3: Após receber um código de autorização do servidor de autorização, o agente usa o fluxo de código de autorização para obter um token de acesso do endpoint de token. Um token de acesso fornece ao agente acesso seguro temporário, confirmando a autenticidade da comunicação e limitando o agente aos escopos OAuth aprovados reivindicados em nome do aplicativo solicitante.

Passo 4: Ao obter um token de acesso, o agente comunica-se com o MCP incluindo o token de acesso no cabeçalho de Autorização como um token de portador. O servidor MCP valida a assinatura do token, a data de expiração e a entidade emissora em relação às chaves públicas do servidor de autorização durante a validação do token para confirmar a identidade do agente.

Passo 5: Quando o agente chama o servidor MCP com o escopo tools:read, o servidor MCP primeiro verifica se os escopos dos tokens de acesso correspondem à ação solicitada. Como o escopo tools:read não permite ações destrutivas, o servidor MCP retorna um Código de Resposta 403 Proibido e registra a negação de acesso como parte do fluxo de autorização.

Passo 6: Para evitar que fluxos de trabalho de automação não autorizados atinjam servidores mal configurados, um motor de políticas ou um gateway MCP é colocado na frente do servidor MCP. O motor de políticas verifica se cada invocação de ferramenta não excede quaisquer limites de taxa ou viola quaisquer políticas baseadas em contexto ou regras baseadas em escopo antes de permitir que a solicitação passe para a lógica do servidor.

Onde as equipes erram com a Autenticação e Autorização MCP?

Mesmo equipes que usam ambas as camadas frequentemente as utilizam de forma incorreta.

• Tratar um token válido como permissão irrestrita: Algumas empresas usam tokens válidos para acesso geral, o que leva os desenvolvedores a criar novos tokens que lhes concedem direitos indevidos. Por meio desses tokens, eles acessam recursos de banco de dados de produção, seja apenas em nível de desenvolvedor, ou, por meio de segurança de autenticação por token, acabam obtendo acesso a recursos de banco de dados que não deveriam, devido a uma configuração inicial que lhes concedia tais direitos.
• Autorização ignorada para servidores MCP internos: Uma fronteira de rede por si só não garante que você não conseguirá acessá-los. Alguém com acesso interno pode acessar todos os recursos internos no servidor de aplicativos de processamento de pedidos de vendas interno.
• Chaves de API estáticas usadas sem uma pilha de autorização adequada: Chaves de API estáticas podem não ter escopos OAuth, expiração ou mecanismos de revogação. Se uma chave de API estática for divulgada em um arquivo de log ou repositório, a única solução é rotacionar as credenciais, o que é operacionalmente disruptivo em larga escala.
• Confiar apenas em escopos OAuth sem RBAC no nível do gateway: Escopos OAuth definem o que o token pode realizar dentro de uma sessão, enquanto as funções definem o que a pessoa está designada a realizar. Se o RBAC não for aplicado no nível do gateway, um pipeline automatizado terá o mesmo acesso que um engenheiro humano.
• Não reavaliar o acesso uma vez que a permissão foi concedida no início de uma sessão: Quando um agente de IA recebe permissão para executar sua função no início da sessão, se a função do agente mudar durante a sessão, todas as permissões concedidas antes dessa mudança continuarão a ser aplicadas por todo o período. Este é um risco significativo em sistemas de agentes onde agentes autônomos podem operar em sessões estendidas.

O que a Implementação Empresarial de Autenticação e Autorização MCP Exige? 

Não é viável para equipes ou implementações de servidores individuais gerenciarem a autenticação MCP e a autorização MCP em escala por conta própria. Em vez disso, elas devem ser implementadas em vários servidores no nível da plataforma.

Para conseguir isso, o seguinte deve ser levado em consideração:

• Gerenciamento centralizado de identidade via um provedor de identidade: Todas as solicitações de autenticação MCP em todos os servidores MCP devem passar pelo mesmo provedor de identidade, seja Okta, Azure AD ou Auth0. A configuração de autenticação distribuída não escalará e criará fragmentação nos rastros de auditoria.
• Tokens com escopo de curta duração, impostos pela infraestrutura: Todos os servidores MCP devem impor tokens de acesso de curta duração com escopos OAuth definidos através da infraestrutura. A equipe não pode definir corretamente a expiração ou o escopo do token para cada implantação, mas a infraestrutura os aplicará de forma consistente.
• RBAC por servidor e função com propagação imediata de políticas: Quando uma equipe altera a função de um usuário ou membro da equipe, a alteração deve ser propagada imediatamente para todos os servidores e se tornar efetiva sem esperar pelo próximo ciclo de implantação.
• Trilhas de auditoria combinadas exclusivas para logs de acesso e autorização: Tanto os logs de acesso quanto os logs de autorização MCP são exigidos por diferentes equipes. Ambas as equipes precisam de acesso a trilhas de auditoria combinadas usando um ID de solicitação comum para futuras investigações.
• Aplicação de controle de acesso do gateway separada do código da aplicação: Se a política da aplicação for armazenada no servidor e o servidor for implantado incorretamente, a política da aplicação pode ser desativada sem detecção. No entanto, o gateway MCP aplicará verificações de escopos OAuth e limites de taxa, independentemente do comportamento da aplicação.

Como a TrueFoundry Aplica Autenticação e Autorização MCP na Camada da Plataforma?

A TrueFoundry trata a autenticação e autorização MCP como conceitos fundamentais de sua plataforma, e não como tarefas a serem realizadas por aplicações individuais.

• Integração IdP empresarial pronta para uso: A TrueFoundry permite que as organizações conectem seu provedor de identidade corporativo usando Okta, Azure AD ou qualquer servidor de autorização OAuth que suporte OAuth 2.0. Tokens de autenticação são provisionados e a verificação de identidade ocorre através da infraestrutura de identidade existente de cada organização. As organizações não precisam criar ou gerenciar um servidor de autorização adicional para completar suas aplicações.
• RBAC por servidor aplicado no gateway, não na aplicação: Ao aplicar o controle de acesso no gateway MCP antes que uma solicitação chegue à lógica da aplicação do servidor MCP, a TrueFoundry garante que as políticas de acesso sejam aplicadas em várias instâncias MCP, independentemente de como cada instância da aplicação é desenvolvida ou implantada.
• Acesso com escopo que mapeia funções organizacionais para permissões de ferramentas: A TrueFoundry suporta o escopo de autorização MCP, com um grupo como Finanças atribuído a um conjunto de ferramentas e outro grupo como Suporte atribuído a outro. Um agente de Finanças e um agente de Suporte podem acessar a mesma infraestrutura MCP, embora tenham permissões de ferramentas distintas. O mapeamento entre funções e escopos OAuth é definido uma vez na plataforma e se aplica a todas as instâncias.
• Trilha de auditoria unificada dentro da sua VPC: A TrueFoundry fornece uma trilha de auditoria única e consolidada dentro da VPC do cliente para eventos associados à validação de tokens e invocações de ferramentas. As equipes de segurança têm acesso a uma trilha de auditoria completa e correlacionada no tempo. Todos os eventos de validação de tokens e invocação de ferramentas incluem um ID de solicitação uniforme, o que torna simples identificar eventos relacionados a um usuário específico em modelos de linguagem grandes e ferramentas externas.
• Padrão da plataforma, não configuração por equipe: Os recursos de autenticação MCP e autorização MCP são habilitados por padrão para todas as organizações. Essas políticas são sempre herdadas pelas aplicações MCP ao implantar agentes de IA, assim, as equipes não precisam criar suas próprias políticas ou implementar a autenticação adequada em cada novo servidor MCP.

A TrueFoundry oferece autenticação e autorização MCP como capacidades fundamentais da plataforma, em vez de uma carga de configuração individual para as organizações que usam suas ferramentas.

Perguntas Frequentes

O que são autenticação MCP e autorização MCP?

Autenticação MCP e autorização MCP são dois conceitos de segurança separados. A autenticação MCP confirma a identidade do cliente MCP antes que o acesso seja concedido, usando tokens OAuth ou chaves de API. A autorização MCP determina o que o cliente autenticado pode fazer por meio de escopos OAuth e RBAC. Ambos são necessários em qualquer implantação de servidor MCP em produção para prevenir riscos de segurança decorrentes de acesso não autorizado.

Qual a diferença entre autenticação e autorização no MCP?

A autenticação MCP ocorre uma vez na conexão e usa o fluxo de código de autorização ou o fluxo de credenciais do cliente para verificar a identidade. A autorização MCP é avaliada em cada invocação de ferramenta durante a conexão, aplicando escopos OAuth e regras RBAC a cada solicitação que o agente de IA faz através do servidor MCP.

É possível ter autorização MCP sem autenticação?

Nenhuma autorização MCP significativa é possível sem autenticação MCP, porque não há uma identidade autenticada contra a qual avaliar as permissões. Sem a autenticação adequada para estabelecer a identidade, o servidor de autorização não tem base para emitir tokens de acesso ou aplicar lógica de autorização a solicitações recebidas de agentes de IA ou agentes autônomos.

O que vem primeiro, autenticação MCP ou autorização MCP?

A autenticação MCP sempre vem primeiro. O fluxo de autorização estabelece a identidade do cliente MCP com o servidor de autorização. A autorização MCP ocorre então para cada solicitação subsequente após a conclusão da autenticação do cliente e a emissão de tokens de acesso com escopos OAuth definidos.

A TrueFoundry suporta o uso do seu próprio IdP?

Sim. O TrueFoundry integra-se com qualquer provedor de identidade compatível com OAuth 2.0 ou servidor de autorização OAuth, permitindo que as organizações reutilizem sua infraestrutura de identidade existente. Isso inclui suporte para provedores de identidade externos como Okta e Azure AD, possibilitando a autenticação MCP centralizada em todos os servidores MCP sem a necessidade de criar uma configuração de servidor de autorização separada.