Todo novo protocolo apresenta suas próprias complexidades. Quando um novo protocolo aparece, a primeira pergunta a fazer é se é realmente necessário. Então, vamos fazer essa pergunta sobre o Model Context Protocol (MCP).
A onda atual de aplicativos Agentic, desencadeada por ferramentas como o ChatGPT, é alimentada por grandes modelos de idiomas (LLMS) que se destacam em tarefas como resumo, criação de conteúdo e processamento de imagens, mas vêm com limitações fundamentais. Nomeadamente:
- Sem acesso a dados em tempo real
- Sem acesso a dados privados
- Nenhuma capacidade de executar ferramentas
O MCP aborda as limitações acima, atuando como um protocolo universal que conecta aplicativos Agentic a dados e ferramentas do mundo real. Mas é justo perguntar: por que apresentar um novo protocolo quando já temos APIs seguras e de alto desempenho?
A resposta curta é que, embora as APIs poderosas de hoje possam ser conectadas a aplicativos Agentic, há um desafio. Essas APIs variam amplamente, por exemplo, REST, GraphQL, GRPC, usando HTTP, Websockets, Pub/Sub. Seus mecanismos de autenticação também diferem, por exemplo, as chaves da API, OAuth2. Isso significa que cada integração é sob medida. Os desenvolvedores devem ler documentos, construir fluxos e conectar APIs um por um.
WSO2
Este modelo de integração estática é comprovado, mas não corresponde à natureza dinâmica dos aplicativos agênticos. É aí que entra o MCP. O MCP define funções claras do cliente-servidor, um formato de protocolo padrão e um ciclo de vida, tornando-se essencialmente o conector universal entre LLMS e sistemas externos. Então você pode pensar no MCP como o USB-C no mundo da API.
Como o MCP funciona
O MCP define três funções principais – um host, um cliente e um servidor:
- HOST: Aplicativos Agentic que gerenciam os ciclos de vida do cliente e aplica a segurança.
- Cliente: conectores leves nos hosts que estabelecem uma sessão 1: 1 com um servidor MCP.
- Servidor: Programas que conectam clientes MCP a fontes e ferramentas de dados, local ou remotamente.
WSO2
Cada função fornece um conjunto de recursos. Os servidores MCP expõem recursos (dados contextuais como eventos do calendário), solicitações (modelos estruturados que orientam a entrada do usuário para melhorar a saída LLM) e as ferramentas (funções executáveis). Os clientes MCP se conectam aos servidores MCP para solicitar dados, executar ferramentas e orquestrar agentes.
O MCP usa o JSON-RPC, um protocolo estruturado e leve para solicitações e respostas, e define dois mecanismos de transporte padrão para comunicação do cliente-servidor, entrada e saída padrão (STDIO) e HTTP transmissível.
Protegendo um servidor MCP local
Quando o servidor MCP é executado localmente, o transporte de stdio deve ser usado. Na prática, isso significa que o aplicativo Agentic inicia o servidor MCP como um subprocesso e se comunica através de seus fluxos de entrada e saída padrão. Como essa comunicação permanece inteiramente dentro do sistema local, ela é inerentemente segura e a especificação do MCP Auth não requer segurança adicional.
WSO2
No entanto, quando um servidor MCP se comunica com as APIs de back-end, normalmente pela Internet, a segurança se torna uma prioridade, mas fica fora do escopo da especificação de autenticação do MCP. No entanto, ainda não há necessidade de novos mecanismos; As práticas de segurança da API existentes são suficientes. As abordagens comuns incluem:
- Tokens de vida longa: as teclas e os tokens da API, válidos por dias ou meses, são obtidos por meio de canais fora da banda e configurados no servidor MCP.
- Tokens de curta duração: Com a vida útil inferior a uma hora, os tokens de curta duração não podem ser definidos manualmente. Em vez disso, o servidor MCP deve solicitá -los dinamicamente no tempo de execução com a aprovação do usuário. OAuth2 Tokens de acesso e JWTs são exemplos típicos.
Protegendo um servidor MCP remoto
Um cliente MCP se conecta a um servidor MCP remoto via HTTP iniciando uma solicitação para o URL do ponto de extremidade. Conforme especificado pelo MCP Auth Spec, esse endpoint deve ser oauth 2.1 protegido, exigindo que o cliente apresente um token de acesso válido.
WSO2
O MCP AUTH SPEC descreve um processo de aquisição de token projetado para suportar integrações dinâmicas e agênticas. Essas interações incluem as etapas a seguir.
WSO2
Descoberta de metadados do servidor
Depois que o URL do servidor MCP é fornecido como um parâmetro de configuração, o cliente constrói um ponto final de metadados do servidor, removendo qualquer componente do caminho e anexando o caminho de autentação e autentação bem conhecido /oauthorização. O cliente recupera um documento de metadados do servidor formatado JSON deste endpoint. Tanto o terminal quanto o documento devem estar em conformidade com a especificação de metadados do OAuth 2.0 Authorization Server. Este metadata ajuda o cliente a descobrir as seguintes informações necessárias durante as próximas etapas:
- Endpoint de registro
- Autorização e terminais de token
- Tipos de concessão suportados e escopos
Deriver o terminal de metadados do servidor do URL do servidor MCP foi destinado a permitir que os clientes operassem com um único parâmetro de configuração. No entanto, isso acopla firmemente as funções de autorização e servidor de recursos, limitando o uso da infraestrutura existente do OAuth 2.0 e das soluções de identidade criadas para fins específicos. Para abordar isso, a próxima especificação de autenticação do MCP substitui esse mecanismo pela especificação de metadados de recursos protegidos do OAuth 2.0.
Registro do cliente
Com base nas informações recuperadas do documento dos metadados do servidor, o aplicativo cliente envia uma solicitação de registro para o terminal de registro do cliente. A especificação de autenticação MCP adota o protocolo OAuth 2.0 Dynamic Client Registration (DCR) para registrar o cliente como um cliente OAuth 2.1. Na resposta do DCR, o aplicativo cliente recebe um client_id e, para clientes confidenciais, um client_secret. Ambos são necessários para a próxima etapa.
Enquanto o DCR é amplamente adotado, as opiniões variam de acordo com o registro aberto, e a própria especificação permite proteger o terminal de registro com o OAuth 2.0. Novamente, para suportar a configuração de parâmetro único, a especificação MCP Auth recomenda o registro aberto. Resta ver como isso evoluirá.
Acesso a recuperação do token
Nesta fase, o cliente tem tudo o que é necessário para solicitar um token de acesso. Dependendo do caso de uso, um dos seguintes tipos de doações OAuth 2.1 é usado:
- Credenciais do cliente: se o aplicativo cliente estiver acessando o servidor MCP diretamente, ele usa a concessão de credenciais do cliente com o
client_ideclient_secretobtidos durante o registro, juntamente com o terminal e os escopos do token descobertos nos metadados do servidor. - Código de autorização: se o cliente acessar o servidor MCP em nome de um usuário final, ele usará a concessão do código de autorização. Este fluxo requer o
client_ideclient_secretA partir de registro e terminal de autorização, terminal de token e escopos dos metadados do servidor. Além disso, conforme exigido pelo OAuth 2.1, o cliente deve usar a chave de prova para o Code Exchange (PKCE) para aprimorar a segurança.
WSO2
Se tudo correr bem, o aplicativo cliente obtém um token de acesso válido e pode iniciar uma solicitação de conexão ao URL do servidor MCP, passando o token através do cabeçalho HTTP da autorização. O servidor MCP valida o token e estabelece a conexão, se for válido.
Por fim, esse fluxo de segurança se alinha aos fluxos típicos de segurança da API baseados em OAuth, exceto pela etapa inicial de derivar o URL dos metadados do servidor no URL do servidor MCP.
Sagara Gunathunga é diretora de arquitetura de soluções da WSO2.
–
Insights generativos de IA Fornece um local para os líderes de tecnologia explorarem e discutirem os desafios e oportunidades da inteligência artificial generativa. A seleção é ampla, desde mergulhos profundos da tecnologia a estudos de caso até opinião de especialistas, mas também subjetivos, com base em nosso julgamento de quais tópicos e tratamentos melhor atenderão ao público tecnicamente sofisticado do Infoworld. O Infoworld não aceita garantia de marketing para publicação e se reserva o direito de editar todo o conteúdo contribuído. Contato [email protected].
