Autorisation dans MCP : selon la spécification en vigueur, réponds d'abord « qui es-tu ? »

Introduction

MCP (Model Context Protocol) est le câblage standard entre les applications d'IA et les outils externes : un hôte MCP (comme Claude Code, Claude Desktop ou VS Code) crée un client par serveur MCP, et les serveurs exposent trois primitives — tools, resources, prompts. Cet article examine son modèle d'autorisation selon la spécification officielle en vigueur d'autorisation de MCP (version 2026-07-28 ; vérifié le 6 octobre 2026 que /specification/latest redirige ici). (Analyse produit au 6 octobre 2026.)[1]

[1] [2]

L'autorisation reste optionnelle

La spécification en vigueur : Authorization is OPTIONAL. Les implémentations en HTTP SHOULD suivre cette spécification ; les serveurs locaux en STDIO SHOULD NOT suivre ce flux OAuth, et récupèrent plutôt les identifiants depuis l'environnement. Notez que c'est SHOULD NOT, pas techniquement impossible : que le local soit sûr dépend de l'isolation des processus et de la garde des identifiants, que la spécification laisse aux implémenteurs.[2]

[2]

Trois rôles

La spécification en vigueur établit une section « Roles » à trois parties : le serveur MCP protégé est le resource server d'OAuth 2.1 ; le client MCP est le client d'OAuth 2.1, effectuant des requêtes de ressources protégées au nom d'un resource owner ; l'authorization server interagit avec l'utilisateur quand nécessaire et émet les access tokens, et peut être hébergé avec le resource server ou comme entité séparée — ses détails d'implémentation sont hors du champ de cette spécification. « Qui émet les tokens » et « qui les reçoit » sont formellement séparés.[2]

[2]

Binding de resource et audience

La spécification en vigueur exige que les clients implémentent Resource Indicators selon RFC 8707 : le paramètre resource MUST figurer dans les requêtes d'autorisation comme de token, identifiant l'URI canonique du serveur MCP visé ; le serveur, comme resource server, MUST vérifier que les access tokens ont été émis spécifiquement pour lui comme audience prévue, n'acceptant que les tokens émis par son propre authorization server pour ses propres ressources, et MUST NOT accepter ni transiter aucun autre token. Tokens liés aux ressources : un token, un lieu.[2]

[2]

DCR obsolète

Dans la spécification en vigueur, l'enregistrement dynamique des clients (DCR) est obsolète et conservé uniquement pour compatibilité ; les authorization servers et clients MCP SHOULD supporter OAuth Client ID Metadata Documents. Avant d'initier le flux d'autorisation, les clients MUST obtenir un client ID par l'un des trois mécanismes — Client ID Metadata Documents, pré-enregistrement ou DCR — dans l'ordre de priorité défini par la spécification.[2]

[2]

Défis de scope et step-up

La spécification en vigueur détaille le traitement des permissions insuffisantes : les serveurs MAY inclure un paramètre scope dans l'en-tête WWW-Authenticate du 401 guidant les permissions requises ; quand un token est rejeté pour scope insuffisant, le serveur SHOULD répondre 403 avec insufficient_scope — notez qu'il s'agit du cas de scope insuffisant ; les tokens invalides ou expirés reçoivent toujours 401. Le client se ré-autorise avec un ensemble élargi de scopes via le flux step-up et réessaie.[2]

Il faut distinguer deux « humains » différents : la ré-autorisation step-up exécute le flux d'autorisation OAuth, que les clients agissant au nom d'un utilisateur SHOULD tenter selon la spécification — et ce flux peut lui-même exiger une interaction de l'utilisateur ; le protocole d'autorisation permet et dans certains cas exige une autorisation interactive. Mais ce n'est pas la même chose que « l'approbation humaine obligatoire pour chaque appel d'outil ». Le premier est un mécanisme à l'intérieur du protocole d'autorisation ; le second est la politique d'appels du host. Ce n'est pas la même chose.[2]

[2]

Le handshake 401

Quand une autorisation est requise et que le client ne l'a pas encore prouvée, le serveur répond HTTP 401 puis le client initie le flux OAuth 2.1 ; les tokens transitent dans l'en-tête Authorization, jamais dans le query string de l'URI (exigence de la Section 5 d'OAuth 2.1 citée par la spécification en vigueur). Les clients comparent exactement tout iss reçu à l’issuer enregistré ; ils ne doivent rejeter l’absence d’iss que lorsque le serveur d’autorisation déclare prendre en charge ce paramètre (RFC 9207).[2]

[2]

La réponse entreprise

L'extension entreprise (au versionnage indépendant) fait de l'IdP de l'organisation le décideur faisant autorité : les employés se connectent une fois et l'IdP décide à quels serveurs MCP ils peuvent accéder selon la politique organisationnelle ; selon la documentation de l'extension, dans les déploiements qui implémentent et supportent l'extension, la révocation se fait en une fois au niveau IdP, avec effet immédiat sur tous les clients. Aucun test pratique des implémentations ; il n'est pas garanti que tous les déploiements MCP se comportent ainsi. L'autorisation individuelle est raisonnable pour les consommateurs ; en entreprise elle crée frictions et failles.[3]

[3]

Commentaire

1. Le protocole ne standardise que le handshake, pas la politique. La section « Roles » place explicitement l'implémentation de l'authorization server hors champ — MCP ne décide même pas « qui émet les tokens ». C'est un design honnête : en évaluant un déploiement, regardez du côté de l'authorization server, pas le câble.

2. L'obsolescence de DCR montre un protocole qui converge. Le passage de « tout enregistrer dynamiquement » à « déclarer d'abord les métadonnées d'identité » déplace la confiance de la négociation à l'exécution vers la déclaration à l'enregistrement. La commodité cède à l'auditabilité : la trajectoire typique d'un protocole qui mûrit.

3. « Au nom de qui » reste l'origine. La spécification en vigueur maintient la distinction dans sa section step-up : « clients agissant au nom d'un utilisateur » contre « clients client_credentials » suivent des flux distincts [2]. Agir en usurpant un utilisateur contre agir comme l'application elle-même impliquent des logiques d'audit et de révocation complètement différentes : demandez d'abord cela, puis les scopes.

4. Le protocole d'autorisation n'est pas l'approbation par action. Les défis de scope et le step-up sont des mécanismes de permissions à l'intérieur du protocole, et le step-up peut impliquer une interaction de l'utilisateur ; mais « l'approbation humaine obligatoire pour chaque appel » est une autre affaire, de la politique du host. En concevant un pipeline de publication avec agents, la couche protocole (« ce token peut-il être utilisé ») et la couche politiques (« cet appel est-il approuvé ») doivent se séparer — comme rédaction, révision et signature ne doivent jamais être les mêmes mains.

5. Quatre questions pour les praticiens (spécification en vigueur). Qui est l'authorization server (avec le resource server ou indépendant) ? Le binding resource/audience est-il réellement appliqué ? Quelle est la stratégie de défis de scope du serveur (comment le 403 est-il utilisé) ? Quel mécanisme d'enregistrement de clients parmi les trois est utilisé ? Si vous ne pouvez répondre, ne connectez pas encore de données de production.

[2]

Ce qui ne peut encore être affirmé

Avec quelle complétude hôtes et clients implémentent la spécification en vigueur (non testé en pratique) ;

Le progrès réel de l'obsolescence de DCR ;

La posture réelle de sécurité de serveurs MCP concrets (selon leur propre documentation et audits).