Como funciona a autenticação MCP? Auditoria da cadeia OAuth

Para um servidor MCP remoto protegido, authentication não é uma verificação de token. É uma cadeia de autorização: o cliente recebe um desafio, descobre metadados para o recurso protegido exato, descobre e valida um servidor de autorização, obtém uma identidade de cliente, executa um fluxo de código de autorização com PKCE e um indicador de recurso, recebe os escopo necessários e prova que o token resultante funciona no ponto final do MCP pretendido. Essa resposta tem um limite importante. O Especificação da autorização do MCP atual torna a autorização opcional e aplica o seu caminho OAuth aos transportes baseados em HTTP. Um servidor STDIO local deve obter credenciais através do seu ambiente de hospedagem ou de outro mecanismo local. Por conseguinte, iniciar um fluxo de navegador para cada conexão MCP não é um padrão razoável. A questão operacional não é tenho um token? É que recibos mostram que cada vinculação nesta cadeia de autorização em particular concorda? Uma cadeia em forma de token pode coexistir com o recurso errado, um emissor não confiável, escopo faltante ou um pedido protegido que ainda retorna 401 . Comece com o transporte e o primeiro desafio O Tutorial de autorização de MCP oficial explica o fluxo HTTP remoto em etapas. Em forma condensada: 1. O cliente envia um pedido de MCP sem um token. 2. O servidor MCP protegido retorna o 401 Unauthorized com um desafio Bearer WWW Authenticate . 3. O desafio aponta para os metadados de recursos protegidos através do resource metadata . 4. Esses metadados identificam o recurso protegido e um ou mais servidores de autorização. 5. O cliente obtém os metadados do servidor de autorização e valida o emissor e os pontos finais. 6. O cliente obtém um ID do cliente através de um mecanismo que o servidor de autorização suporta, em seguida, executa o fluxo de código de autorização com PKCE e o identificador de recursos MCP. 7. O cliente envia o token de acesso resultante para o servidor MCP e observa o pedido protegido. O primeiro 401 não é uma falha de supressão. É um recibo de descoberta. Um registro útil mantém o status HTTP, esquema de autenticação, URL de metadados, tempo de observação e recurso MCP selecionado. Znot mantém o cabeçalho Authorization , cookies, código de autorização, verificador, segredo do cliente ou token de acesso. O RFC 9728 define os metadados de recursos protegidos e o padrão de descoberta bem conhecido. O seu valor de segurança depende da autoridade: os metadados para o https://mcp.example/mcp devem descrever esse recurso, e não um host similar ou um URL fornecido por um serviço não relacionado. Seguir uma URL de autorização arbitrária de um corpo de erro não é equivalente. O servidor de autorização é um papel separado. Um servidor MCP protegido atua como um servidor de recursos OAuth; o cliente MCP atua como um cliente OAuth; o servidor de autorização interage com o usuário quando necessário e emite tokens de acesso. A confusão dessas funções faz com que um erro comum de resolução de problemas pareça plausível: girar um token de servidor de recursos antes de verificar se o cliente descobriu o emissor correto. Ligue o recurso, emissor, cliente e fluxo de código Duas URLs merecem uma comparação exata. O primeiro é o recurso protegido. O RFC 8707 define o parâmetro de solicitação resource para que um servidor de autorização conheça o destinatário pretendido de um token. O projeto atual do MCP requer o parâmetro de recursos em solicitações de autorização e de tokens. Um token de acesso emitido para outra API não é quase válido para o servidor MCP selecionado. O segundo é o emissor do servidor de autorização. Antes de abrir o navegador, um cliente registra o emissor a partir de metadados validados do servidor de autorização. Quando uma resposta de autorização inclui iss , o projeto atual do MCP descreve a comparação com esse valor registrado antes que o cliente envie o código para um ponto final de token. Uma descoincidência do emissor é uma condição de parada, não um motivo para tentar o mesmo código contra ambos os pontos finais. O registo do cliente é também uma camada explícita. Um cliente pode usar um documento de metadados de ID do cliente, um ID do cliente pré registrado ou um caminho de registo dinâmico suportado. O projeto atual trata o Registro Dinâmico de Clientes como um mecanismo de compatibilidade e não como uma suposição universal. Se não existir nenhum mecanismo de registo suportado, o veredicto correto é registration blocked ; a invenção de um URI de redireção ou a reutilização de outro ID de cliente de produto oculta a falha de interoperabilidade real. O PKCE vincula o pedido de autorização à troca de código posterior. A auditoria registra apenas se o fluxo manteve um verificador vinculado, nunca o próprio verificador. Uma ligação faltante torna se unsafe flow , mesmo que um navegador devolva um código. Aqui está a forma livre de conteúdo usada para um aparelho saudável: Os nomes dos escopo são evidências de configuração, não valores secretos. Em uma implantação sensível, eles ainda podem revelar capacidades, por isso retêm apenas o que a decisão de saúde precisa e aplicam os mesmos controles de acesso que outros metadados operacionais. Diagnóstico da primeira camada falhada Uma lista de verificação plana produz ações contraditórias. Se os metadados de recursos protegidos não estiverem disponíveis, a comparação entre emissores não terá entrada confiável. Se o identificador de recurso for errado, o pedido de um âmbito mais amplo não o corrigirá. O classificador utiliza, por conseguinte, a prioridade e termina na primeira camada falhada: O veredicto Evidências que pararam a cadeia Ação seguinte limitada not applicable Transporte local de estúdios Usar o mecanismo local de credenciamento runtime invalid challenge Falta ou não de HTTPS resource metadata Repare o desafio 401 metadata unavailable Metadados de recursos protegidos não foram devolvidos para 200 Restaurar metadados; não adivinhar o emissor resource mismatch Metadados ou tokens visam um recurso diferente Corrigir a identidade de recurso ou solicitar um token vinculado a recursos issuer mismatch Discovered ou callback emissor discordar Rejeitar o fluxo e investigar a autoridade de metadados registration blocked Nenhuma identidade de cliente suportada Configurar um mecanismo de registo suportado unsafe flow Fluxo de código de autorização não tem ligação PKCE Reiniciar com PKCE step up required A operação atual precisa de um escopo não concedido Solicitar apenas o âmbito de aplicação impugnado token rejected Os compromissos concordam, mas o pedido protegido ainda falha Classificar o novo desafio antes da rotação authorized ready Todos os recibos de autorização concordam e o pedido é bem sucedido Continuar com a inicialização do MCP e os controlos de resultados O dispositivo fornecido pode ser reproduzido sem acesso à rede: A sua execução datada produziu dez casos, dez veredictos de primeira camada, um authorized ready e secretFieldsStored: 0 . Esse resultado é intencionalmente mais rigoroso do que 9 erros e um sucesso. Prova que a regra de decisão preserva diferenças significativas entre um transporte local, descoberta falhada, identidade contraditória, registro não suportado, fluxo de código inseguro, escassez de alcance e token rejeitado. A regra da primeira camada fracassada também limita as reincidências. A metadata unavailable pode justificar uma retestada de metadados limitados. issuer mismatch não deve. A step up required pode justificar um novo fluxo de consentimento para o âmbito de aplicação contestado. A token rejected exige a leitura do novo desafio porque a expiração, a revogação, o público e o escopo não compartilham uma reparação. Mantenha o escopo de aceleração separado do falha do token O projeto atual do MCP recomenda que um servidor inclua o escopo necessário no seu desafio WWW Authenticate . O âmbito de aplicação contestado para a operação em curso é autorizado para essa operação; não é necessário que seja igual ao conjunto inteiro de metadados de recurso scopes supported . Isto altera a decisão do operador. Suponha que uma leitura tenha sucesso com files:read , então uma escrita retorna 403 e desafios para files:write . Isso não é prova de que a loja de símbolos é corrupta. É um estado step up required . O cliente deve solicitar a permissão faltante com visibilidade humana e conservar as permissões ainda necessárias para outras operações. Em contrapartida, um pedido protegido que devolva o 401 após o recurso, emissor, registo, PKCE e receitas de âmbito concordarem é o token rejected . O próximo passo seguro é classificar o novo desafio. Repetidamente apresentar o mesmo símbolo é atividade, não progresso. A rotação de todas as credenciais também pode destruir evidências úteis e interromper clientes saudáveis. O veredicto do authorized ready continua estreito. Diz que o servidor MCP remoto aceitou a cadeia de autorização para este pedido. Não diz: A inicialização do MCP e a negociação de capacidade tiveram êxito; A ferramenta selecionada ainda existe ou o seu esquema permanece inalterado; Uma chamada de ferramenta produziu o efeito externo pretendido; um efeito colateral é seguro para retomar após um intervalo de tempo; Existe a entregabilidade do utilizador; O servidor de autorização, o cliente e o recurso são globalmente confiáveis. São decisões subsequentes de saúde e segurança. Uma solicitação protegida bem sucedida deve transferir a execução para os controlos do ciclo de vida do MCP, em seguida, para a verificação do efeito e dos resultados das ferramentasnão diretamente para o agente saudável. Usar o recibo sem coletar credenciais Para operações de produção, armazenar hashes ou IDs estáveis para o cliente e recurso selecionados apenas quando forem necessários para correlacionar eventos. Registrar timestamps e versão de especificações porque os metadados e as regras de protocolo evoluem. Mantenha o token bruto, código, verificador, segredo, cookie, prompt, argumentos de ferramenta e resultados de ferramenta fora do registro de saúde. O artefato é um classificador, não uma suite de conformidade ao vivo. Confia nas observações que lhe foram fornecidas. Uma implementação real deve também validar TLS, origem de metadados, redirecionamento de URI, comportamento do emissor, assinaturas de tokens ou introspecção, público, expiração e política de implantação. O esboço do MCP foi verificado em 30 de julho de 2026; fixa a especificação que implementar e reinicie a fixação quando o contrato mudar. O território do produto destinado à Sidewisp inclui a acessibilidade das ferramentas, as credenciais expiradas, a perda de permissão, o progresso útil e a verificação dos resultados. A Sidewisp está atualmente em prévia privada. Os seus adaptadores de monitoramento de produção e o executor de recuperação geralmente não são enviados, por isso este artigo fornece uma regra de operação independente em vez de afirmar que a Sidewisp já realiza essa auditoria de autorização do MCP. A resposta prática para como funciona a autenticação do MCP? é, portanto, uma cadeia de recibos de autorização, não uma captura de tela do token portador. Tratar a primeira contradição como o diagnóstico, aplicar uma reparação limitada e manter o sucesso da autorização separado do sucesso da ferramenta e do resultado final do usuário.