Autorização no MCP: pela especificação vigente, primeiro responda «quem é você?»

Introdução

MCP (Model Context Protocol) é a fiação padrão entre aplicações de IA e ferramentas externas: um host MCP (como Claude Code, Claude Desktop ou VS Code) cria um cliente para cada servidor MCP, e os servidores expõem três primitivas — tools, resources, prompts. Este artigo examina seu modelo de autorização pela especificação oficial vigente de autorização do MCP (versão 2026-07-28; verificado em 6 de outubro de 2026 que /specification/latest redireciona para cá). (Análise de produto até 6 de outubro de 2026.)[1]

[1] [2]

A autorização segue opcional

A especificação vigente: Authorization is OPTIONAL. Implementações que usam HTTP SHOULD seguir esta especificação; servidores locais que usam STDIO SHOULD NOT seguir este fluxo OAuth, e em vez disso obtêm as credenciais do ambiente. Note que é SHOULD NOT, não tecnicamente impossível: a segurança do local depende do isolamento de processos e da custódia de credenciais, que a especificação deixa aos implementadores.[2]

[2]

Três papéis

A especificação vigente estabelece uma seção «Roles» com três partes: o servidor MCP protegido é o resource server do OAuth 2.1; o cliente MCP é o client do OAuth 2.1, fazendo solicitações de recursos protegidos em nome de um resource owner; o authorization server interage com o usuário quando necessário e emite access tokens, podendo estar hospedado com o resource server ou como entidade separada — seus detalhes de implementação estão fora do escopo desta especificação. «Quem emite os tokens» e «quem os recebe» ficam formalmente separados.[2]

[2]

Binding de resource e audience

A especificação vigente exige que os clientes implementem Resource Indicators conforme a RFC 8707: o parâmetro resource MUST aparecer tanto nas solicitações de autorização quanto nas de token, identificando a URI canônica do servidor MCP a que o token se destina; o servidor, como resource server, MUST verificar que os access tokens foram emitidos especificamente para ele como audience pretendida, aceitando apenas tokens emitidos por seu próprio authorization server para seus próprios recursos, e MUST NOT aceitar nem transitar quaisquer outros tokens. Tokens presos a recursos: um token, um lugar.[2]

[2]

DCR obsoleto

Na especificação vigente, o registro dinâmico de clientes (DCR) está obsoleto e é mantido apenas por compatibilidade; authorization servers e clientes MCP SHOULD suportar OAuth Client ID Metadata Documents. Antes de iniciar o fluxo de autorização, os clientes MUST obter um client ID por um de três mecanismos — Client ID Metadata Documents, pré-registro ou DCR — na ordem de prioridade definida pela especificação.[2]

[2]

Desafios de scope e step-up

A especificação vigente detalha o tratamento de permissões insuficientes: os servidores MAY incluir um parâmetro scope no cabeçalho WWW-Authenticate do 401 orientando as permissões requeridas; quando um token é rejeitado por scope insuficiente, o servidor SHOULD responder 403 com insufficient_scope — note que este é o caso de scope insuficiente; tokens inválidos ou expirados seguem recebendo 401. O cliente se reautoriza com um conjunto maior de scopes via fluxo step-up e tenta de novo.[2]

É preciso distinguir dois «humanos» diferentes: a reautorização step-up executa o fluxo de autorização OAuth, que os clientes agindo em nome de um usuário SHOULD tentar conforme a especificação — e esse fluxo pode exigir interação do usuário; o protocolo de autorização permite e em alguns casos exige autorização interativa. Mas isso não é o mesmo que «aprovação humana obrigatória para cada chamada de ferramenta». O primeiro é um mecanismo dentro do protocolo de autorização; o segundo é política de chamadas do host. Não são a mesma coisa.[2]

[2]

O handshake 401

Quando a autorização é exigida e o cliente ainda não a demonstrou, o servidor responde HTTP 401 e o cliente então inicia o fluxo OAuth 2.1; os tokens trafegam no cabeçalho Authorization, nunca na query string da URI (requisito da Seção 5 do OAuth 2.1 citado pela especificação vigente). Os clientes comparam exatamente qualquer iss recebido com o issuer registrado; só devem rejeitar a ausência de iss quando o servidor de autorização declara suporte a ele (RFC 9207).[2]

[2]

A resposta empresarial

A extensão empresarial (com versionamento independente) transforma o IdP da organização no decisor autoritativo: os funcionários fazem login uma vez e o IdP decide a quais servidores MCP podem acessar conforme a política organizacional; conforme a documentação da extensão, nas implantações que implementam e suportam a extensão, a revogação acontece uma vez na camada IdP, com efeito imediato em todos os clientes. Sem testes práticos de implementações; não se garante que todas as implantações MCP se comportem assim. A autorização individual é razoável para consumidores; em empresas cria fricção e brechas.[3]

[3]

Comentário

1. O protocolo só padroniza o handshake, não a política. A seção «Roles» deixa explicitamente a implementação do authorization server fora do escopo — o MCP nem decide «quem emite os tokens». É um design honesto: ao avaliar uma implantação, olhe o lado do authorization server, não o fio.

2. A obsolescência do DCR mostra um protocolo em convergência. A passagem de «registrar dinamicamente tudo» para «declarar primeiro os metadados de identidade» desloca a confiança da negociação em tempo de execução para a declaração no registro. A conveniência cede à auditabilidade: a trajetória típica de um protocolo que amadurece.

3. «Em nome de quem» segue sendo a origem. A especificação vigente mantém a distinção em sua seção step-up: «clientes agindo em nome de um usuário» versus «clientes client_credentials» seguem fluxos distintos [2]. Agir se passando por um usuário versus agir como a própria aplicação implicam lógicas de auditoria e revogação completamente distintas: pergunte isto primeiro, depois os scopes.

4. O protocolo de autorização não é aprovação por ação. Desafios de scope e step-up são mecanismos de permissão dentro do protocolo, e o step-up pode envolver interação do usuário; mas «aprovação humana obrigatória para cada chamada» é outro assunto, da política do host. Ao desenhar um pipeline de publicação com agentes, a camada de protocolo («este token pode ser usado») e a de políticas («esta chamada está aprovada») devem se separar — como redação, revisão e assinatura nunca devem ser as mesmas mãos.

5. Quatro perguntas para profissionais (especificação vigente). Quem é o authorization server (junto ao resource server ou independente)? O binding de resource/audience é realmente aplicado? Qual a estratégia de desafios de scope do servidor (como o 403 é usado)? Qual dos três mecanismos de registro de clientes é usado? Se não puder responder, ainda não conecte dados de produção.

[2]

O que ainda não pode ser afirmado

Com que completude hosts e clientes implementam a especificação vigente (não testado na prática);

O progresso real da obsolescência do DCR;

A postura real de segurança de servidores MCP concretos (conforme sua própria documentação e auditorias).