01Modèle de rôles : le serveur MCP comme resource server
Depuis la révision 2025-06-18, un serveur MCP protégé agit comme resource server OAuth 2.1 : il reçoit et valide les access tokens, mais ne les émet pas lui-même ; le client MCP agit comme client OAuth pour le compte de l'utilisateur. L'authorization server constitue un rôle distinct – il peut être hébergé avec le resource server, mais son implémentation sort du périmètre de la spécification. Il n'en a pas toujours été ainsi : la révision 2025-03-26 traitait de facto le serveur MCP comme authorization server et resource server à la fois, avec des endpoints par défaut /authorize, /token et /register directement sur le serveur MCP. La séparation formelle décharge les opérateurs de serveurs et permet de recourir à des fournisseurs d'identité établis plutôt qu'à une émission de tokens maison.
02Chaîne de discovery : RFC 9728 et RFC 8414
Le client localise l'authorization server compétent à l'exécution plutôt que par configuration : à une requête sans token valide, le serveur MCP répond par 401 Unauthorized et renvoie, via l'en-tête WWW-Authenticate, vers ses Protected Resource Metadata (RFC 9728) – un document obligatoire dont le champ authorization_servers désigne au moins un authorization server. De là, le client charge les Authorization Server Metadata selon RFC 8414 (/.well-known/oauth-authorization-server) avec les endpoints d'autorisation, de token et d'enregistrement ; c'est alors seulement que commence le véritable flux OAuth 2.1. Cette discovery à l'exécution remplace la configuration codée en dur – un point décisif pour les agents qui ne se voient attribuer leurs outils qu'à l'exécution. La révision 2025-11-25 ajoute OpenID Connect Discovery et un repli .well-known sans en-tête ; la révision 2026-07-28 ajoute la validation de l'issuer selon RFC 9207 contre les attaques de type mix-up.
03Enregistrement des clients : RFC 7591 et CIMD
Parce que des clients MCP quelconques rencontrent des serveurs quelconques, l'enregistrement manuel des clients ne passe pas à l'échelle. La révision 2025-06-18 recommande donc (SHOULD) le Dynamic Client Registration selon RFC 7591 : le client s'enregistre lui-même auprès de l'endpoint d'enregistrement et reçoit son propre client_id – en pratique le plus souvent comme public client sans client secret ; les alternatives sont un client ID préconfiguré ou la saisie manuelle. La révision 2026-07-28 déclare toutefois le DCR deprecated et mise sur les Client ID Metadata Documents (CIMD) introduits avec la révision 2025-11-25 : des identités client fondées sur des URL. Elle précise en même temps que les client credentials stockés sont liés à l'authorization server émetteur et ne doivent pas être réutilisés au-delà des frontières d'un serveur. Le DCR continue de fonctionner à titre transitoire pour des raisons de compatibilité – les nouvelles implémentations devraient connaître les deux voies.
04Règles de base OAuth 2.1 : PKCE, en-têtes, durées de vie courtes
OAuth 2.1 fait table rase des héritages non sûrs d'OAuth 2.0 : l'implicit grant et le password grant disparaissent, les redirect URIs ne sont plus comparées qu'à l'identique, et PKCE est obligatoire – les clients MCP DOIVENT implémenter PKCE, en pratique avec la méthode de challenge S256 plutôt que « plain ». Les access tokens doivent figurer comme bearer tokens dans l'en-tête Authorization de chaque requête et ne doivent jamais apparaître dans la query string de l'URI ; tous les endpoints de l'authorization server fonctionnent en HTTPS, les redirect URIs sont limitées à localhost ou à HTTPS. Les refresh tokens des public clients doivent, selon OAuth 2.1, être sender-constrained ou des tokens à usage unique avec rotation. Les recommandations pratiques courantes ajoutent des access tokens à durée de vie courte, de quelques minutes, ainsi qu'une détection de réutilisation qui révoque toute la famille de tokens lorsqu'un ancien refresh token est réutilisé.
05Liaison d'audience (RFC 8707) et interdiction du token passthrough
Un token doit être émis pour exactement un serveur MCP : les clients DOIVENT envoyer le paramètre resource selon RFC 8707 dans les requêtes d'autorisation et de token, en y indiquant l'URI canonique du serveur cible ; le serveur DOIT vérifier qu'il est bien l'intended audience et rejeter avec un 401 les tokens étrangers ou expirés. L'interdiction du passthrough est tout aussi stricte : un serveur MCP NE DOIT PAS transmettre le token reçu du client à des API en aval, mais y agir comme client OAuth à part entière avec son propre token. Sinon se profile le problème du confused deputy – le serveur agit comme mandataire abusé avec des privilèges qui ne sont pas les siens, et le rate limiting, le monitoring et la piste d'audit de l'API en aval tournent à vide. Les serveurs proxy à client ID statique DOIVENT en outre recueillir un consentement utilisateur distinct pour chaque client enregistré dynamiquement, faute de quoi des cookies de consentement réutilisés dirigent des authorization codes vers des attaquants.
06MCP07 en pratique : constats et contrôles
L'OWASP MCP Top 10 (version v0.1, bêta – pas un standard finalisé) classe ce domaine sous MCP07 « Insufficient Authentication & Authorization ». Le constat de terrain est accablant : Trend Micro a trouvé en 2025 au total 492 serveurs MCP exposés sur Internet sans authentification ni chiffrement du transport, l'audit d'Astrix a dénombré 53 pour cent de clés API statiques contre seulement 8,5 pour cent d'OAuth, et la CVE-2025-6514 dans le paquet npm mcp-remote (CVSS 9,6) a montré que de simples champs de discovery OAuth manipulés peuvent déclencher une exécution de code. Les contrôles efficaces partent de la spécification : OAuth 2.1 avec PKCE et un authorization server séparé, des tokens à durée de vie courte et liés à l'audience plutôt que du passthrough – avec token exchange selon RFC 8693 pour les appels en amont –, un consentement par client dans les proxys et le serveur MCP comme non-human identity à part entière dans l'IAM. Deux questions d'audit pour l'audit interne et la direction : y a-t-il un token passthrough quelque part dans la chaîne – et combien de temps vit un token d'agent ?
