Fiche concept

Autorisation MCP — OAuth 2.0 et gating par tier

À jour au 2026-07-24T14:00:00Z

Édité par Cédric-Olivier Mâry, éditeur et directeur de la publication — 27 ans d'écosystème SAP. Comment ces pages sont produites, et où intervient l'automatisation.

Qu'est-ce que Autorisation MCP — OAuth 2.0 et gating par tier ?

La spec MCP 2025-06-18 impose OAuth 2.1 pour le transport HTTP, 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.

La révision de la spécification MCP de juin 2025 embarque un modèle d'autorisation formel pour le transport Streamable HTTP. 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 cela existe

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).

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, supprimant l'étape manuelle de provisionnement du client-id qui bloquerait sinon l'onboarding en self-service des agents.
Decision owner: La personne responsable qui assume l'arbitrage et finance l'action suivante.
Semantic contract: La définition partagée des termes métier, métriques, entités et règles d'accès utilisée par les outils et les équipes.
Control plane: La couche qui applique la politique, l'accès, la traçabilité, la supervision et l'escalade à travers le modèle opérationnel.
Evidence grade: Une étiquette qui distingue le fait vérifié, le signal directionnel, l'hypothèse modélisée et l'observation de terrain.

Sources

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.

Ouvrir dans l'application →