Análise detalhada da especificação de autorização MCP (edição de 2025-03-26)

MCP (Model Context Protocol) é um padrão aberto que permite que os modelos de IA interajam com ferramentas e serviços externos. É amplamente adotado pela indústria. Como o MCP suporta métodos de transporte baseados em HTTP, o Servidor MCP remoto desempenhará um papel cada vez mais importante no ecossistema MCP.

Ao contrário do Servidor MCP local, que permite que cada usuário execute sua própria instância de servidor, o Servidor MCP remoto exige que todos os usuários compartilhem o mesmo serviço de Servidor MCP. Isso levanta o problema central que a Especificação de Autorização MCP visa resolver: como permitir que o Servidor MCP acesse recursos do usuário em nome do usuário.

Este artigo analisará a Especificação de Autorização MCP em profundidade. Vai te ajudar a entender os princípios de design da especificação de autorização MCP e algumas direções para implementar a autorização MCP. Uma vez que esta especificação ainda está evoluindo, vou compartilhar algumas ideias baseadas na minha experiência pessoal em implementar o Authenticator, incluindo:

• Vantagens e limitações do OAuth 2.1 como um framework de autorização
• Desafios dos papéis duplos do Servidor MCP como Servidor de Autorização e Servidor de Recursos
• Complexidade prática de implementar um Servidor de Autorização completo
• Análise de cenários adequados para autorização delegada de terceiros
• Concessões práticas do Registro Dinâmico de Clientes
• Importância de definir claramente os limites de recursos do Servidor MCP

Visão geral da Especificação de Autorização MCP#

A Especificação de Autorização MCP define o processo de autenticação entre o Servidor MCP (Remoto) e o Cliente MCP.

Acredito que basear essa especificação no OAuth 2.1 é uma escolha muito razoável. O OAuth como um protocolo de autorização resolve o problema de como permitir que os usuários autorizem aplicativos de terceiros a acessar recursos do usuário em seu nome. Se você não está familiarizado com o OAuth, pode verificar o AuthWiki-OAuth para mais informações.

No cenário de Cliente MCP e Servidor MCP, trata-se de "usuários autorizando o Cliente MCP a acessar recursos do usuário no Servidor MCP". Os "recursos do usuário no Servidor MCP" atualmente referem-se principalmente a ferramentas fornecidas pelo Servidor MCP ou recursos fornecidos pelos serviços de backend do Servidor MCP.

Para implementar o processo de autenticação OAuth 2.1, o protocolo requer que um Servidor MCP forneça as seguintes interfaces para trabalhar com o Cliente MCP para concluir o processo de autenticação OAuth 2.1:

• /.well-known/oauth-authorization-server: metadados do servidor OAuth
• /authorize: ponto final de autorização, usado para solicitações de autorização
• /token: ponto final de token, usado para troca e renovação de token
• /register: ponto final de registro do cliente, usado para registro dinâmico de clientes

O processo de autenticação é o seguinte:

A especificação também especifica como o Servidor MCP suporta autorização delegada através de servidores de autorização de terceiros.

O fluxo de exemplo na especificação é o seguinte (do conteúdo da especificação):

Nesse cenário, embora o Servidor MCP delegue autorização para um servidor de autorização de terceiros, o Servidor MCP ainda atua como um servidor de autorização para o Cliente MCP. Isso ocorre porque o Servidor MCP precisa emitir seu próprio token de acesso para o Cliente MCP.

Na minha visão, este cenário parece mais adequado para lidar com situações em que o Servidor MCP proxyia o Cliente MCP (usuário) para acessar recursos de terceiros (como repositórios do Github), em vez de o Servidor MCP proxyiar o Cliente MCP (usuário) para acessar seus próprios recursos do Servidor MCP.

Em resumo, de acordo com o protocolo, o Servidor MCP desempenha tanto o papel de Servidor de Autorização quanto de Servidor de Recursos no OAuth.

Em seguida, vamos discutir as responsabilidades do Servidor MCP como Servidor de Autorização e Servidor de Recursos.

Servidor MCP como serviço de autorização#

Quando o Servidor MCP atua como Servidor de Autorização, significa que o usuário final do Cliente MCP tem sua própria identidade no Servidor MCP. O Servidor MCP é responsável por autenticar esse usuário final e emitir um token de acesso para que esse usuário final acesse os recursos do Servidor MCP.

As interfaces relacionadas à autorização exigidas pela Especificação de Autorização MCP mencionadas acima significam que o Servidor MCP deve fornecer uma implementação de Servidor de Autorização.

No entanto, implementar a funcionalidade de Servidor de Autorização no Servidor MCP é um desafio significativo para os desenvolvedores. Por um lado, a maioria dos desenvolvedores pode não estar familiarizada com conceitos relacionados ao OAuth. Por outro lado, há muitos detalhes a considerar ao implementar o Servidor de Autorização. Se um desenvolvedor não for de uma área relacionada, eles podem introduzir problemas como problemas de segurança durante a implementação.

No entanto, o próprio protocolo não limita o Servidor MCP a somente implementar a funcionalidade do Servidor de Autorização. Os desenvolvedores podem completamente redirecionar ou proxyar esses endpoints relacionados à autorização para outros servidores de autorização. Isso não é diferente para o Cliente MCP do que o Servidor MCP implementar a funcionalidade do Servidor de Autorização por conta própria.

Você pode se perguntar, este abordagem deve usar o método de autorização delegada de terceiros mencionado acima?

Do meu ponto de vista, isso depende principalmente de se os usuários do serviço de autorização de terceiros em que você confia são os mesmos que os usuários finais do Servidor MCP. Isso significa que o token de acesso emitido para você pelo serviço de autorização de terceiros será consumido diretamente pelo seu Servidor MCP.

• Se sim, você pode completamente encaminhar interfaces relacionadas à autenticação no seu Servidor MCP para serviços de autorização de terceiros.

• Se não, então você deve usar a abordagem de autorização delegada de terceiros especificada na especificação. Você precisa manter uma relação de mapeamento entre tokens de acesso emitidos pelo próprio Servidor MCP e tokens de acesso emitidos por serviços de autorização de terceiros no Servidor MCP.

Acredito que a abordagem de autorização delegada de terceiros especificada no protocolo é um tanto vaga em cenários de aplicação prática. O protocolo parece estar permitindo que terceiros ajudem o Servidor MCP a completar o processo de autorização, mas ainda exige que o Servidor MCP emita seu próprio token de acesso. Na verdade, isso significa que o Servidor MCP ainda carrega a responsabilidade de emitir tokens de acesso como Servidor de Autorização, o que não é mais conveniente para os desenvolvedores. Acredito que provavelmente é porque os autores do protocolo consideraram que retornar diretamente os tokens de acesso de terceiros para o Cliente MCP traria alguns problemas de segurança (como vazamento/abuso, etc.).

Da minha experiência, o cenário mais adequado para a autorização delegada de terceiros especificada no protocolo deve ser o cenário de "usuários autorizando o Servidor MCP a acessar recursos de terceiros". Por exemplo, um Servidor MCP precisa acessar um repositório Github de um usuário e implantar o código do repositório em uma plataforma de implantação de código. Neste caso, o usuário precisa autorizar o Servidor MCP a acessar seu repositório Github e acessar a plataforma de implantação de código.

Nesse cenário, o Servidor MCP é um Servidor de Autorização para o Cliente MCP, pois os usuários finais têm sua própria identidade no Servidor MCP. O Servidor MCP é um Cliente de terceiros para recursos de terceiros (neste caso, o Github). Ele precisa obter autorização do usuário para acessar recursos do usuário no Github. Entre o Cliente MCP e o Servidor MCP, e entre o Servidor MCP e recursos de terceiros, as identidades dos usuários são separadas. Isso faz com que seja significativo manter uma relação de mapeamento entre tokens de acesso emitidos pelo próprio Servidor MCP e tokens de acesso emitidos por serviços de autorização de terceiros no Servidor MCP.

Portanto, o protocolo de autorização delegada de terceiros no protocolo deve resolver o problema de "como os usuários autorizam o Servidor MCP a acessar recursos do usuário em Servidores de Recursos de terceiros".

Servidor MCP como Servidor de Recursos#

Quando o Servidor MCP atua como Servidor de Recursos, o Servidor MCP precisa verificar se a solicitação do Cliente MCP transporta um token de acesso válido. O Servidor MCP decidirá se permite que o Cliente MCP acesse recursos específicos com base no escopo do token de acesso.

Pela definição do MCP, o Recurso fornecido pelo Servidor MCP deve ser ferramentas para o Cliente MCP usar. Nesse cenário, o Servidor MCP só precisa decidir se fornece aos usuários acesso a certas ferramentas.

Mas em cenários do mundo real, essas ferramentas fornecidas pelo Servidor MCP também precisam interagir com o Servidor de Recursos do próprio provedor de serviços do Servidor MCP. Nesse momento, o token de acesso obtido pelo Servidor MCP a partir da solicitação do cliente precisa ser usado para acessar seu próprio Servidor de Recursos. Na maioria dos casos, o Servidor MCP e o Servidor de Recursos por trás das ferramentas são do mesmo desenvolvedor. O Servidor MCP é apenas uma interface fornecida por seus próprios recursos de backend para o Cliente MCP usar. Nesse momento, o Servidor MCP pode compartilhar o mesmo token de acesso emitido por um Servidor de Autorização com os recursos de backend.

Neste caso, em vez de dizer que o Servidor MCP é um Servidor de Recursos, fornecendo ferramentas e o Recurso do serviço por si só, é melhor dizer que o Servidor de Recursos existente se torna um Servidor MCP, fornecendo ferramentas para o Cliente MCP chamar.

Incluir recursos fornecidos pelo seu próprio Servidor de Recursos no Recurso fornecido pelo Servidor MCP é mais por consideração de cenários do mundo real. Mas pessoalmente, ainda prefiro que o Recurso fornecido pelo Servidor MCP tenha apenas ferramentas usadas pelo cliente MCP, e os recursos de que as ferramentas dependem devem ser recursos obtidos pelo Servidor MCP de outros Servidores de Recursos (incluindo de primeira e terceira partes). Desta forma, todos os cenários do mundo real podem ser cobertos.

Como funciona a autorização MCP#

Depois de entender as responsabilidades do Servidor MCP como Servidor de Autorização e Servidor de Recursos, podemos saber como a Autorização MCP funciona especificamente:

Registro Dinâmico de Clientes#

A especificação também define como o Servidor de Autorização identifica os Clientes. O OAuth 2.1 fornece o Protocolo de Registro Dinâmico de Clientes, permitindo que o Cliente MCP obtenha automaticamente o ID do cliente OAuth sem intervenção manual do usuário.

De acordo com a especificação, o Servidor MCP deve suportar o Protocolo de Registro Dinâmico de Clientes do OAuth 2.0. Desta forma, o Cliente MCP pode se registrar automaticamente com novos servidores para obter o ID do cliente OAuth. Esta abordagem é recomendada em cenários MCP principalmente porque:

• O Cliente MCP não pode conhecer todos os possíveis servidores antecipadamente
• O registro manual causaria transtornos para os usuários
• Ele torna a conexão com novos servidores transparente
• Os servidores podem implementar suas próprias políticas de registro

No entanto, de uma perspectiva prática, tenho algumas reflexões sobre a aplicação do Registro Dinâmico de Clientes em cenários MCP:

• Em práticas de serviços OAuth, o Cliente geralmente corresponde um a um a um aplicativo específico de negócios. Criar clientes dinamicamente pode não ser propício para gerenciar efetivamente recursos relacionados (usuários, aplicativos, etc.) em serviços OAuth. Os provedores de serviços OAuth geralmente desejam ter controle claro sobre os clientes conectados, em vez de permitir que qualquer cliente se registre como Cliente livremente.
• Muitos serviços OAuth não recomendam ou permitem que os usuários criem Clientes dinamicamente, pois isso pode levar ao abuso do serviço. A maioria dos provedores de serviços OAuth maduros (como GitHub, Google, etc.) exige que os desenvolvedores registrem manualmente Clientes através de seu console de desenvolvedor, e pode ser necessário fornecer informações detalhadas sobre o aplicativo, URL de callback, etc.
• Registrar manualmente o Cliente OAuth é na verdade uma tarefa única durante o desenvolvimento, não algo que cada usuário final precisa fazer. Não causará um grande ônus para os desenvolvedores.
• Para Cliente Público (como aplicativos nativos, aplicativos de página única, etc.), temos maneiras mais seguras de implementar o fluxo OAuth sem registro dinâmico. O ID do Cliente combinado com o PKCE (Prova de Chave para Troca de Código) pode fornecer um fluxo OAuth seguro o suficiente para Clientes Públicos sem a criação dinâmica de Cliente.
• Embora o protocolo aponte que o uso do Registro Dinâmico dos Clientes pode evitar que os clientes precisem conhecer o ID do Cliente com antecedência, na verdade, o Cliente MCP sempre precisa conhecer o endereço do Servidor MCP Remoto com antecedência. Se for assim, especificar o ID do Cliente ao passar o endereço do Servidor MCP Remoto não trará muito problema adicional. Ou, também podemos criar uma convenção para o Cliente MCP perguntar ao Servidor MCP pelo ID do Cliente, o que não é uma tarefa difícil.

Embora o Registro Dinâmico de Clientes forneça flexibilidade para o ecossistema MCP em teoria, em implementação prática, podemos precisar considerar se realmente precisamos desse mecanismo de registro dinâmico. Para a maioria dos provedores de serviços, criar e gerenciar Clientes OAuth manualmente pode ser uma maneira mais controlável e segura.

Resumo#

Este artigo analisa profundamente a filosofia de design e os desafios de implementação da Especificação de Autorização MCP. Como uma estrutura de autorização baseada no OAuth 2.1, esta especificação visa resolver o problema chave de como o Servidor MCP Remoto acessa recursos do usuário em nome dos usuários.

Através de uma discussão detalhada dos papéis duplos do Servidor MCP como Servidor de Autorização e Servidor de Recursos, bem como dos prós e contras de mecanismos como Registro Dinâmico de Clientes e delegação de autorização de terceiros, este artigo fornece reflexões e sugestões da experiência pessoal na implementação do Authenticator.

Vale a pena notar que a especificação de autorização MCP ainda está evoluindo. Como membro da equipe Logto, continuaremos a prestar atenção aos últimos desenvolvimentos dessa especificação e a otimizar nossas soluções de implementação na prática para contribuir com a interação segura entre modelos de IA e serviços externos.