Autorização no MCP 2026-07-28: verificações do emissor e mudanças no registro de clientes

O que é

Situação em 25 de outubro de 2026. As mudanças de autorização de 2026-07-28 dizem respeito à validação do emissor, ao registro e à vinculação das credenciais. Antes da implantação, conferir novamente a especificação de autorização da versão, as regras de registro e os metadados do servidor de autorização. Os Client ID Metadata Documents (CIMD) não são uma novidade desta revisão: o histórico de mudanças de 2025-11-25 já os recomenda. A nova revisão torna formalmente obsoleto o Dynamic Client Registration (DCR), mantendo-o por compatibilidade.

O servidor MCP é o recurso protegido, o cliente MCP obtém acesso e o servidor de autorização emite tokens. Portanto, as mudanças podem caber a serviços diferentes, mesmo quando um único operador administra todos eles. A estrutura OAuth do MCP aplica-se a implantações HTTP; não é o mecanismo de credenciais prescrito para stdio.

Por que importa

Um fluxo de autorização deve permanecer associado ao emissor selecionado no seu início. Caso contrário, mudanças de endpoint ou registros ambíguos podem levar ao uso de credenciais com o servidor de autorização errado. CIMD também introduz responsabilidades de obtenção de documentos e validação de redirecionamentos; reconhecer um identificador de cliente em formato de URL não estabelece confiança na aplicação.

Como aplicar

• Validar as respostas de autorização antes de trocar o código por tokens. Os clientes registram o emissor dos metadados validados do servidor junto com o verificador PKCE da tentativa de autorização. Os servidores de autorização devem, de preferência, retornar iss e, quando o fizerem, são obrigados a anunciar suporte. Os clientes comparam qualquer iss retornado com o valor registrado, exigindo igualdade exata após a decodificação do formulário, sem normalização de URL. Uma divergência é rejeitada, inclusive em respostas de erro. Se os metadados anunciarem suporte ao parâmetro de emissor, mas iss estiver ausente, rejeitar; se o suporte não for anunciado e o parâmetro não for fornecido, a especificação permite prosseguir.
• Vincular as credenciais de registro ao emissor. Armazenar as credenciais de pré-registro ou DCR sob o identificador do servidor que as emitiu. Nunca reutilizá-las com outro emissor. Obter registro para o novo servidor; em caso de divergência no pré-registro, apresentar um erro. Essa regra não torna um identificador CIMD hospedado pelo próprio cliente específico de um emissor: a especificação de registro permite explicitamente que esse identificador de URL seja portável sem novo registro.
• Seguir as regras de seleção do registro. Dar preferência ao pré-registro disponível, depois ao CIMD quando anunciado por client_id_metadata_document_supported e, por último, ao DCR suportado como alternativa de compatibilidade. Um documento CIMD usa HTTPS com um caminho e inclui client_id, client_name e redirect_uris. Seu client_id deve ser igual à URL do documento; validar o JSON e o redirecionamento solicitado em relação ao documento.
• Reforçar a segurança da obtenção de metadados. Aplicar as defesas documentadas contra falsificação de requisições do lado do servidor ao buscar documentos de clientes. Considerar políticas de confiança em domínios. CIMD, por si só, não impede a personificação de aplicações envolvendo redirecionamentos para localhost; exibir o nome do host de redirecionamento durante a autorização, conforme exigido.
• Manter o DCR legado correto. Os clientes devem especificar um application_type adequado. Recomenda-se que aplicações nativas de desktop, CLI e localhost usem native; para aplicações remotas de navegador, recomenda-se usar web. Investigar falhas de registro em vez de flexibilizar as verificações de redirecionamento para fazê-las desaparecer.
• Manter o nível mínimo de segurança existente. Verificar o suporte a PKCE nos metadados, proteger os tokens armazenados e validar se os tokens recebidos se destinam a este recurso MCP. Chamadas a APIs upstream precisam de tokens upstream emitidos separadamente. A migração do registro não permite o repasse de tokens nem a remoção das verificações de consentimento.

Armadilhas

Não descrever DCR como já removido, nem CIMD como universalmente obrigatório: seu suporte é uma recomendação. Como teste de aceitação proposto, testar em homologação respostas com emissor correto, divergente e ausente, uma mudança de emissor e cada fluxo de registro mantido. Verificar se as respostas rejeitadas nunca chegam à etapa de troca do código por tokens. Essas verificações visam à conformidade com o protocolo; não constituem uma auditoria de segurança de uma implantação específica de autorização.