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

MCP (Protocolo de Contexto de Modelo) é um padrão aberto que permite que 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 terá 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 os recursos do usuário em nome do usuário.

Este artigo analisará a Especificação de Autorização MCP em profundidade. Isso ajudará você a entender os princípios de design da Especificação de Autorização MCP e algumas direções para implementar a Autorização MCP. Como esta Especificação ainda está evoluindo, compartilharei alguns pensamentos com base na minha experiência pessoal na implementação do Autenticador, incluindo:

• Vantagens e limitações do OAuth 2.1 como framework de autorização
• Desafios dos papéis duais 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
• Trocas 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.

Acho que basear esta Especificação no OAuth 2.1 é uma escolha muito razoável. O OAuth como framework de 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 estiver familiarizado com o OAuth, você pode conferir AuthWiki-OAuth para mais informações.

No cenário do 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 às ferramentas fornecidas pelo Servidor MCP ou aos recursos fornecidos pelos serviços de backend do Servidor MCP.

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

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

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):

Neste cenário, embora o Servidor MCP delegue a autorização a 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 opinião, esse cenário parece mais adequado para lidar com situações onde o Servidor MCP proxy o Cliente MCP (usuário) para acessar recursos de terceiros (como repositórios do Github), ao invés de o Servidor MCP proxy o Cliente MCP (usuário) para acessar os próprios recursos do Servidor MCP.

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

A seguir, 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 possa acessar 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 se considerar ao implementar o Servidor de Autorização. Se um desenvolvedor não for da área relacionada, pode introduzir problemas como problemas de segurança durante a implementação.

Contudo, o próprio protocolo não limita o Servidor MCP a apenas implementar a funcionalidade de Servidor de Autorização ele mesmo. Os desenvolvedores podem completamente redirecionar ou colocar em proxy 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 de Servidor de Autorização por conta própria.

Você pode estar se perguntando, essa abordagem deve usar o método de autorização de terceiros delegado 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, então você pode encaminhar completamente as interfaces relacionadas ao Auth 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 de terceiros delegada especificada na Especificação. Você precisa manter um relacionamento 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.

Acho que a abordagem de autorização de terceiros delegada 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 seus próprios tokens de Acesso. Isso na verdade 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. Eu acho que provavelmente é porque os autores do protocolo consideraram que retornar diretamente tokens de acesso de terceiros ao 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 de terceiros delegada 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 o Repositório do Github de um usuário e implantar o código do Repositório em uma plataforma de implantação de código. Nesse caso, o usuário precisa autorizar o Servidor MCP a acessar seu Repositório do Github e acessar a plataforma de implantação de código.

Neste cenário, o Servidor MCP é um Servidor de Autorização para o Cliente MCP, porque os usuários finais têm sua própria identidade no Servidor MCP. O Servidor MCP é um Cliente de terceiro 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 do usuário estão separadas. Isso torna significativo manter um relacionamento 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 de terceiros delegado 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 carrega 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.

Na definição do MCP, o Recurso fornecido pelo Servidor MCP deve ser ferramentas para o Cliente MCP usar. Neste cenário, o Servidor MCP apenas precisa decidir se fornece ou não aos usuários o 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 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 recursos de backend.

Neste caso, em vez de dizer que o Servidor MCP é um Servidor de Recursos, fornecendo ferramentas e Recursos do próprio serviço, é melhor dizer que o Servidor de Recursos existente se torna um Servidor MCP ao fornecer 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 eu pessoalmente ainda prefiro que o Recurso fornecido pelo Servidor MCP tenha apenas ferramentas usadas pelo cliente MCP, e os recursos que as ferramentas dependem devem ser recursos obtidos pelo Servidor MCP de outros Servidores de Recursos (incluindo de primeiro e terceiro). Desta forma, todos os cenários do mundo real podem ser cobertos.

Como funciona a autorização MCP#

Após 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 de 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 registrar-se automaticamente com novos servidores para obter o ID de cliente OAuth. Esta abordagem é recomendada nos cenários MCP principalmente porque:

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

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

• Em práticas reais de serviços OAuth, o Cliente geralmente é um para um em relação a um App de negócio específico. Criar Clientes dinamicamente pode não ajudar na gestão eficaz de recursos relacionados (usuários, App, etc.) nos 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 não 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.) requerem que desenvolvedores registrem manualmente os Clientes através de seus consoles de desenvolvedor, e podem também precisar de informações detalhadas sobre o aplicativo, URL de retorno, etc.
• Registrar manualmente o Cliente OAuth é na verdade um trabalho único durante o desenvolvimento, não algo que cada usuário final precisa fazer. Não causará um grande fardo sobre os desenvolvedores.
• Para Cliente Público (tais como aplicativos nativos, aplicações de página única, etc.), temos formas mais seguras de implementar o fluxo OAuth sem registro dinâmico. O ID de Cliente combinado com PKCE (Prova de Chave para Troca de Código) pode proporcionar um fluxo OAuth seguro o suficiente para Clientes Públicos sem criar Clientes dinamicamente.
• Embora o protocolo aponte que usar o Registro Dinâmico de Clientes pode evitar que os clientes precisem saber o ID de Cliente antecipadamente, na verdade, o Cliente MCP sempre precisa saber o endereço do Servidor MCP Remoto antecipadamente. Se assim for, especificar o ID de Cliente enquanto passa o endereço do Servidor MCP Remoto não trará muito problema extra. Ou, também podemos criar uma convenção para o Cliente MCP solicitar ao Servidor MCP o 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, na implementação prática, podemos precisar considerar se realmente necessitamos desse mecanismo de registro dinâmico. Para a maioria dos provedores de serviços, criar e gerenciar manualmente o Cliente OAuth pode ser uma forma 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 um framework de autorização baseado 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 de usuários.

Através de uma discussão detalhada dos papéis duais 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 pensamentos e sugestões a partir de experiências pessoais na implementação do Autenticador.

É importante notar que a especificação de autorização MCP ainda está evoluindo. Como membro da equipe Logto, continuaremos a observar os últimos desenvolvimentos desta especificação e continuamente otimizar nossas soluções de implementação na prática para contribuir para a interação segura entre modelos de IA e serviços externos.