Comment fonctionne l'authentification MCP ? Audit de la chaîne OAuth

Pour un serveur MCP distant protégé, authentification n'est pas une vérification de jeton. Il s'agit d'une chaîne d'autorisation: le client reçoit un défi, découvre des métadonnées pour la ressource protégée exacte, découvre et valide un serveur d'autorisation, obtient une identité client, exécute un flux de code d'autorisation avec PKCE et un indicateur de ressource, reçoit les champs requis et prouve que le jeton résultant fonctionne au point final de MCP prévu. Cette réponse a une limite importante. Le Spécification de l'autorisation de MCP actuel rend l'autorisation facultative et applique son chemin OAuth aux transports basés sur HTTP. Un serveur STDIO local devrait obtenir les informations d'identification par l'intermédiaire de son environnement hôte ou d'un autre mécanisme local. Le démarrage d'un flux de navigateur pour chaque connexion MCP n'est donc pas un défaut raisonnable. La question opérationnelle n'est pas ai je un jeton? C'est quels reçus montrent que chaque liaison dans cette chaîne d'autorisation particulière est d'accord? Une chaîne en forme de jeton peut coexister avec la mauvaise ressource, un émetteur non fiable, une portée manquante ou une demande protégée qui renvoie toujours 401 . Commencez par le transport et le premier défi Le Tutoriel d'autorisation du MCP officiel explique le flux HTTP à distance en étapes. En forme condensée: 1. Le client envoie une demande MCP sans jeton. 2. Le serveur MCP protégé renvoie 401 Unauthorized avec un défi WWW Authenticate porteur. 3. Le défi se réfère aux métadonnées de ressources protégées par l'intermédiaire de resource metadata . 4. Ces métadonnées identifient la ressource protégée et un ou plusieurs serveurs d'autorisation. 5. Le client récupère les métadonnées du serveur d'autorisation et valide l'émetteur et les points d'exécution. 6. Le client obtient un identifiant client par un mécanisme que le serveur d'autorisation prend en charge, puis exécute le flux de code d'autorisation avec PKCE et l'identificateur de ressource MCP. 7. Le client envoie le jeton d'accès résultant au serveur MCP et observe la demande protégée. Le premier 401 n'est pas un échec à supprimer. C'est un reçu de découverte. Un enregistrement utile conserve l'état HTTP, le schéma d'authentification, l'URL des métadonnées, le temps d'observation et la ressource MCP sélectionnée. C' est vrai . pas Gardez le Authorization en tête, cookies, code d'autorisation, vérificateur, secret client ou jeton d'accès. RFC 9728 définit les métadonnées de ressources protégées et le modèle de découverte bien connu. Sa valeur de sécurité dépend de l'autorité: les métadonnées pour https://mcp.example/mcp doivent décrire cette ressource, et non un hôte similaire ou une URL fournie par un service non lié. Suivre une autorisation arbitraire URL d'un corps d'erreur n'est pas équivalent. Le serveur d'autorisation est un rôle distinct. Un serveur MCP protégé agit comme un serveur de ressources OAuth; le client MCP agit comme un client OAuth; le serveur d'autorisation interagit avec l'utilisateur lorsque cela est nécessaire et émet des jetons d'accès. La conflation de ces rôles rend plausible une erreur commune de résolution de problèmes: faire tourner un jeton de serveur de ressources avant de vérifier si le client a découvert l'émetteur correct. Lier la ressource, l'émetteur, le client et le flux de code Deux URL méritent une comparaison exacte. La première est la ressource protégée. RFC 8707 définit le paramètre de demande resource afin qu'un serveur d'autorisation connaisse le destinataire prévu d'un jeton. Le projet actuel du MCP exige le paramètre de ressources dans les demandes d'autorisation et de jetons. Un jeton d'accès émis pour une autre API n'est pas quasiment valide pour le serveur MCP sélectionné. Le second est l'émetteur de serveur d'autorisation. Avant d'ouvrir le navigateur, un client enregistre l'émetteur à partir de métadonnées validées du serveur d'autorisation. Lorsqu'une réponse d'autorisation inclut iss , le projet MCP actuel décrit la comparaison avec cette valeur enregistrée avant que le client n'envoie le code à un point d'extrémité de jeton. Un défaut d'émetteur est une condition d'arrêt, pas une raison d'essayer le même code contre les deux terminaux. L'enregistrement du client est aussi une couche explicite. Un client peut utiliser un document de métadonnées d'identification de client, un identifiant de client préréglé ou un chemin d'enregistrement dynamique pris en charge. Le projet actuel traite l'enregistrement dynamique des clients comme un mécanisme de compatibilité plutôt qu'une hypothèse universelle. S'il n'existe aucun mécanisme d'enregistrement pris en charge, le verdict correct est registration blocked ; l'invention d'un URI de redirection ou la réutilisation d'un autre identifiant client du produit cacherait la défaillance réelle d'interopérabilité. PKCE lie la demande d'autorisation à l'échange de code ultérieur. L'audit n'enregistre que si le flux a conservé un vérificateur lié, jamais le vérificateur lui même. Une liaison manquante devient unsafe flow , même si un navigateur renvoie un code. Voici la forme sans contenu utilisée pour un appareil sain: Les noms de champs sont des preuves de configuration, pas des valeurs secrètes. Dans un déploiement sensible, ils peuvent toujours révéler des capacités, donc ne conserver que ce dont la décision de santé a besoin et appliquer les mêmes contrôles d'accès que les autres métadonnées opérationnelles. Diagnostication de la première couche défaillante Une liste de contrôle uniforme produit des actions contradictoires. Si les métadonnées de ressources protégées ne sont pas disponibles, la comparaison des émetteurs n'a pas d'entrée fiable. Si l'identifiant de ressource est erroné, une demande de portée plus large ne le réparera pas. Le classificateur utilise donc la priorité et s'arrête à la première couche défaillante: Le verdict Des preuves qui ont arrêté la chaîne L'action suivante est limitée not applicable Transports locaux Utilisez le mécanisme local de référencement de l'heure d'exécution invalid challenge Manque ou non de HTTPS resource metadata Réparer le défi 401 metadata unavailable Les métadonnées des ressources protégées n'ont pas été retournées à 200 Restaurer les métadonnées; ne deviner pas l'émetteur resource mismatch Les métadonnées ou les jetons ciblent une ressource différente Correction de l'identité de la ressource ou demande d'un jeton lié aux ressources issuer mismatch Découverte ou réaction de l'émetteur Rejeter le flux et enquêter sur l'autorité des métadonnées registration blocked Aucune identité de client prise en charge Configurer un mécanisme d'enregistrement pris en charge unsafe flow Le flux de code d'autorisation manque d'une liaison PKCE Réinitialiser avec PKCE step up required L'opération actuelle a besoin d'une portée non accordée Requérir uniquement la portée manquante contestée token rejected Les obligations s'accordent, mais la demande protégée échoue toujours Classifier le nouveau défi avant la rotation authorized ready Tous les reçus d'autorisation sont d'accord et la demande réussit Continuer à l'initialisation et aux vérifications des résultats du MCP L'appareil fourni peut être reproduit sans accès au réseau: Son cours daté a produit dix affaires, dix verdicts de première couche, un authorized ready , et secretFieldsStored: 0 . Ce résultat est intentionnellement plus strict que neuf erreurs et un succès. Il prouve que la règle de décision préserve des différences significatives entre un transport local, une découverte ratée, une identité contradictoire, un enregistrement non pris en charge, un flux de code dangereux, une portée manquante et un jeton rejeté. La règle de la première couche échouée limite également les renouvellements. metadata unavailable peut justifier une nouvelle tentative de métadonnées limitées. issuer mismatch ne devrait pas. step up required peut justifier un nouveau flux de consentement pour le champ d'application contesté. token rejected nécessite la lecture du nouveau défi parce que l'expiration, la révocation, le public et la portée ne partagent pas une seule réparation. Gardez l'amplification de la portée séparée de l'échec des jetons Le projet actuel du MCP recommande à un serveur d'inclure la portée requise dans son défi WWW Authenticate . Le champ d'application contesté pour l'opération en cours est autoritaire pour cette opération; il n'est pas nécessaire qu'il soit égal à l'ensemble des métadonnées de la ressource scopes supported . Cela modifie la décision de l'exploitant. Supposons qu'une lecture réussisse avec files:read , puis une écriture renvoie 403 et des défis pour files:write . Ce n'est pas la preuve que le magasin de symboles est corrompu. Il s'agit d'un état step up required . Le client doit demander l'autorisation manquante à la vue humaine et conserver les autorisations encore nécessaires pour d'autres opérations. En revanche, une demande protégée qui renvoie 401 après que les reçus de ressources, l'émetteur, l'enregistrement, PKCE et la portée ont été acceptés est token rejected . La prochaine étape sûre est de classer le nouveau défi. Présenter à plusieurs reprises le même symbole est une activité, pas un progrès. La rotation de chaque carte d'identité peut également détruire des preuves utiles et interrompre les clients en bonne santé. Le verdict de authorized ready reste étroit. Il dit que le serveur MCP a accepté la chaîne d'autorisation pour cette demande. Il ne dit pas: L'initialisation du PCM et la négociation des capacités ont été couronnées de succès; l'outil sélectionné existe toujours ou son schéma est inchangé; un appel à l'outil a produit l'effet externe prévu; un effet secondaire est sans danger de réessayer après une pause; le livrable de l'utilisateur existe; le serveur d'autorisation, le client et la ressource sont dignes de confiance à l'échelle mondiale. Ce sont des décisions de santé et de sécurité ultérieures. Une demande protégée réussie devrait transférer l'exécution dans les contrôles de cycle de vie du MCP, puis la vérification de l'effet des outils et des résultats non directement à l'agent sain. Utilisez le reçu sans recueillir des informations d'identification Pour les opérations de production, stocker des hashs ou des identifiants stables pour le client et la ressource sélectionnés uniquement lorsqu'ils sont nécessaires pour corréler les événements. Enregistrer les timestamps et la version des spécifications car les métadonnées et les règles du protocole évoluent. Gardez le jeton brut, le code, le vérificateur, le secret, le cookie, le prompt, les arguments de l'outil et les résultats de l'outil hors du dossier médical. L'artefact est un classifiateur, pas une suite de conformité en direct. Il fait confiance aux observations qui lui sont fournies. Une mise en œuvre réelle doit également valider le TLS, l'origine des métadonnées, les URIs de redirection, le comportement de l'émetteur, les signatures de jetons ou l'introspection, le public, l'expiration et la politique de déploiement. Le projet de MCP a été vérifié le 30 juillet 2026; fixez la spécification que vous mettez en œuvre et redémarrez le fichier lorsque ce contrat change. Le territoire prévu du produit Sidewisp comprend la disponibilité des outils, les informations d'identification expirées, la perte de permis, les progrès utiles et la vérification des résultats. Sidewisp est actuellement en préversion privée. Ses adaptateurs de surveillance de la production et son exécuteur de récupération ne sont généralement pas expédiés, donc cet article fournit une règle d'exploitation indépendante plutôt que de prétendre que Sidewisp effectue déjà cet audit d'autorisation MCP. La réponse pratique à comment fonctionne l'authentification MCP? est donc une chaîne de reçus d'autorisation, et non pas une capture d'écran du jeton porteur. Traiter la première contradiction comme le diagnostic, appliquer une réparation limitée, et garder le succès de l'autorisation séparé du succès de l'outil et du résultat final de l'utilisateur.