Autorisation MCP — OAuth 2.0 et gating par tier
À jour au 2026-10-05
Qu'est-ce que Autorisation MCP ?
Le modèle d'autorisation de MCP, formalisé une première fois dans la spec 2025-06-18 puis affiné jusqu'au 28 juillet 2026, impose OAuth 2.1 dès qu'un serveur choisit de prendre en charge l'autorisation sur transport HTTP (l'autorisation elle-même reste optionnelle au niveau du protocole) — mais l'identité seule ne suffit pas — les serveurs commerciaux ont besoin d'une couche de tier-gating qui renvoie -32601, jamais -32603, pour ne pas révéler l'existence d'outils payants.
De quoi il s'agit
La révision de la spécification MCP de juin 2025 a embarqué pour la première fois un modèle d'autorisation formel pour le transport Streamable HTTP ; ce modèle a depuis été reconduit et affiné, en dernier lieu dans la révision du 28 juillet 2026. Le transport stdio s'exécute dans le même processus et fait confiance à la frontière de processus du système d'exploitation, il n'a donc besoin d'aucune couche d'authentification externe. Le modèle HTTP repose sur OAuth 2.1, le profil consolidé et durci d'OAuth 2.0, avec PKCE obligatoire pour tout client, l'enregistrement dynamique de client selon la RFC 7591, et des indicateurs de ressource selon la RFC 8707. Un serveur expose un document de découverte à un chemin bien connu qui oriente les clients vers son serveur d'autorisation ; les clients exécutent le flux authorization-code avec PKCE et présentent un jeton porteur à chaque requête JSON-RPC. Les indicateurs de ressource lient un jeton à un serveur MCP spécifique, ce qui empêche qu'un jeton émis pour un service soit rejoué contre un autre.
Pourquoi c'est important
- Le stdio ne nécessite aucune authentification (frontière OS), mais tout serveur MCP exposé en réseau doit tourner sous OAuth 2.1 avec PKCE, enregistrement dynamique de client (RFC 7591) et resource indicators (RFC 8707) pour lier un token à un serveur unique.
- Le tier-gating traduit l'identité en sous-ensemble d'outils : le tier Discover gratuit voit find_firms en champs publics, Buyer ajoute les fiches complètes, Practice ajoute search_news, Recruiter ajoute les outils côté opportunité.
- Renvoyer -32603 au lieu de -32601 pour un appel hors-tier divulgue l'existence d'outils premium à un appelant non authentifié.
Points clés
- OAuth 2.1 + PKCE pour le transport HTTP (le stdio est in-process, confiance OS) ; spec 2025-06-18 impose PKCE pour clients publics.
- Découverte — /.well-known/oauth-protected-resource pointe vers le serveur d'autorisation ; enregistrement dynamique RFC 7591.
- Token porteur dans l'en-tête Authorization à chaque appel JSON-RPC ; resource indicators (RFC 8707) lient le token à un serveur MCP spécifique.
- Couche tier-gating — traduit l'identité du token en sous-ensemble d'outils ; les appels non autorisés renvoient -32601 method not found, pas -32603 (fuite).
- Stripe Meters + Worker rate-limit — facturation d'usage par-dessus OAuth (the platform charter modèle Année-2 ; §20.5 substrat Cloudflare).
- L'autorisation est optionnelle au niveau protocole (spec 2026-07-28) — un serveur PEUT tourner sans authentification sur HTTP ; s'il prend en charge l'autorisation, il DOIT suivre la spec. Les serveurs stdio NE DEVRAIENT PAS la superposer du tout.
- L'enregistrement dynamique de client RFC 7591 est désormais déprécié (spec 2026-07-28) — les OAuth Client ID Metadata Documents (une URL HTTPS comme client_id) sont le chemin d'enregistrement préféré ; le DCR n'est plus qu'un repli de compatibilité ascendante.
- Protection contre les attaques par confusion (mix-up) — le client doit valider la valeur `iss` de la réponse d'autorisation contre l'émetteur enregistré (RFC 9207), une exigence ajoutée depuis la révision 2025-06-18.
Termes employés sur cette page
- OAuth 2.1 with PKCE
- Le profil OAuth consolidé qu'adopte le transport HTTP de MCP ; PKCE (Proof Key for Code Exchange) est obligatoire pour les clients publics et remplace les flux implicite et par mot de passe, éliminant deux classes de vulnérabilité au vol de token de longue date.
- Resource indicator (RFC 8707)
- Une extension OAuth qui lie un token d'accès à une ressource protégée spécifique (l'URL du serveur MCP) ; un token émis pour le serveur A ne peut pas être rejoué contre le serveur B, même si les deux partagent un serveur d'autorisation.
- Tier-gating layer
- Le contrôle côté serveur, superposé à OAuth, qui associe une identité authentifiée au sous-ensemble d'outils que le palier payant de l'utilisateur l'autorise à appeler ; les appels non autorisés renvoient -32601 (méthode introuvable), jamais -32603 (qui divulguerait l'existence d'outils payants).
- Dynamic client registration (RFC 7591)
- L'extension OAuth qui permet à un client MCP de s'enregistrer par programme auprès du serveur d'autorisation au premier contact. Depuis la révision de la spec MCP du 28 juillet 2026, ce mécanisme est explicitement déprécié et n'est conservé que pour les serveurs d'autorisation qui ne prennent pas encore en charge les OAuth Client ID Metadata Documents.
- OAuth Client ID Metadata Document
- Le mécanisme d'enregistrement préféré depuis la spec MCP 2026-07-28 : le client_id du client est lui-même une URL HTTPS ; le serveur d'autorisation récupère un document de métadonnées JSON à cette URL pour connaître les redirect URIs et propriétés du client, supprimant le besoin d'un aller-retour d'enregistrement séparé (RFC 7591) ou d'un pré-enregistrement manuel.
- OAuth 2.0 Protected Resource Metadata (RFC 9728)
- Le mécanisme de découverte qu'un serveur MCP DOIT implémenter (spec 2026-07-28) : un document bien connu qui indique au client quel(s) serveur(s) d'autorisation le protègent et quels scopes il prend en charge, afin que le client puisse localiser le serveur d'autorisation avant de demander un token.
- Issuer validation (RFC 9207)
- Une défense contre les attaques par confusion (mix-up) ajoutée au flux d'autorisation de MCP : le client enregistre l'identifiant d'émetteur du serveur d'autorisation avant de rediriger l'utilisateur, puis valide la valeur `iss` renvoyée dans la réponse d'autorisation par rapport à cette valeur enregistrée avant de jamais envoyer le code d'autorisation à un endpoint de token.
- Step-up authorization / insufficient_scope
- Le flux d'exécution formalisé (spec 2026-07-28) pour le cas où les scopes d'un token sont trop étroits pour une opération : le serveur renvoie un HTTP 403 avec `error="insufficient_scope"` et les scopes requis ; le client se réautorise avec l'union des scopes déjà accordés et des scopes nouvellement requis, sans perdre les permissions antérieures.
Sources
- MCP specification — Authorization
- IETF OAuth 2.1 draft
- RFC 7591 OAuth Dynamic Client Registration
- Model Context Protocol — Authorization specification, revision 2026-07-28
- Model Context Protocol — Client Registration (spec 2026-07-28)
- Model Context Protocol — Authorization Security Considerations (spec 2026-07-28)
- Model Context Protocol — Authorization Server Discovery (spec 2026-07-28)
- Model Context Protocol — Specification changelog, 2026-07-28
- IETF — OAuth 2.0 Protected Resource Metadata, RFC 9728
- IETF — OAuth 2.0 Authorization Server Issuer Identification, RFC 9207
- IETF — OAuth 2.0 Authorization Server Metadata, RFC 8414
- RFC 8707 — Resource Indicators for OAuth 2.0 (binds a token to one MCP server)
- RFC 7636 — Proof Key for Code Exchange (PKCE) by OAuth Public Clients (why PKCE is required for all clients)
- RFC 6750 — OAuth 2.0 Bearer Token Usage (WWW-Authenticate challenge and 403 insufficient_scope used for step-up)
- IETF OAuth WG — OAuth Client ID Metadata Document draft (HTTPS URL as client_id; MCP's preferred registration mechanism)
- MCP specification 2026-07-28 — Security Best Practices (confused-deputy, token passthrough, session risks)
- Cloudflare Agents docs — MCP authorization (vendor documentation, OAuth for remote MCP servers)
Fiche complète réservée aux abonnés. Ce que la fiche complète ajoute : le cadre de décision complet · la comparaison SAP · Snowflake · Databricks · Fabric · les pièges courants et leur correctif · l'aide-mémoire · les schémas d'architecture · les blocs de code · les chiffres à citer.