Serveur MCP distant : l'authentification OAuth

Un serveur MCP (Model Context Protocol) distant protège ses outils avec OAuth 2.1, le standard de délégation d'accès du web : le serveur MCP joue le rôle de serveur de ressources, l'application d'IA celui de client OAuth, et un serveur d'autorisation (le vôtre ou celui d'un fournisseur d'identité) délivre les jetons. Le client découvre tout seul où s'authentifier grâce aux métadonnées publiées par le serveur. Ce qui suit résume la spécification d'autorisation de la version 2026-07-28, lue le 15/11/2026 ; elle ne remplace pas sa lecture complète.

Quand l'autorisation s'applique

L'autorisation est facultative dans MCP. Quand vous la mettez en place :

• sur un transport HTTP, suivez cette spécification ;
• sur stdio, ne la suivez pas : le serveur prend ses identifiants dans l'environnement (variables d'environnement passées par l'application) ;
• sur un autre transport, appliquez les bonnes pratiques de sécurité propres à ce transport.

Le déroulé, étape par étape

1. Première requête sans jeton. Le serveur MCP répond 401 Unauthorized avec un en-tête WWW-Authenticate qui indique l'adresse de ses métadonnées, et idéalement les droits (scopes) nécessaires :

   HTTP/1.1 401 Unauthorized
   WWW-Authenticate: Bearer resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource",
                            scope="files:read"
   

2. Métadonnées de ressource protégée (RFC 9728, une norme de l'IETF, l'organisme qui publie les standards d'Internet). Le serveur MCP doit les publier ; elles indiquent quel serveur d'autorisation utiliser.
3. Découverte du serveur d'autorisation. Il doit proposer les métadonnées OAuth 2.0 (RFC 8414) ou la découverte OpenID Connect ; le client doit savoir lire les deux.
4. Enregistrement du client, par l'une de trois voies : document de métadonnées du client (le client utilise une adresse HTTPS comme identifiant ; voie recommandée), client pré-enregistré, ou enregistrement dynamique (RFC 7591), désormais déprécié et gardé pour compatibilité.
5. Autorisation. Le client génère les paramètres PKCE (une protection du code d'autorisation contre l'interception), ajoute le paramètre resource, choisit les droits demandés, note l'émetteur attendu, puis ouvre le navigateur.
6. Retour et vérification. Le client vérifie le paramètre iss (l'émetteur, RFC 9207) avant d'échanger le code contre un jeton.
7. Appels MCP avec Authorization: Bearer <jeton> dans chaque requête HTTP. Jamais de jeton dans l'adresse.

Les règles qui évitent les failles

• Paramètre resource (RFC 8707) : le client doit l'envoyer dans la demande d'autorisation et dans la demande de jeton, avec l'adresse canonique du serveur MCP (par exemple https://mcp.example.com/mcp, sans fragment, de préférence sans barre oblique finale).
• Audience des jetons : le serveur doit vérifier que le jeton a été émis pour lui. Un jeton invalide ou expiré reçoit un 401.
• Pas de transmission de jeton : le serveur ne doit accepter ni faire transiter aucun autre jeton. S'il appelle une API (interface de programmation) en aval, il lui faut un jeton émis pour cette API, pas celui reçu du client.
• Droits insuffisants : réponse 403 Forbidden avec error="insufficient_scope" et les droits manquants ; le client relance une autorisation qui ajoute ces droits à ceux déjà obtenus.
• Jetons de rafraîchissement : le client les garde confidentiels et ne suppose jamais qu'il en recevra.

Bien choisir les droits (scopes)

La spécification recommande le moindre privilège : scopes_supported devrait lister le minimum nécessaire au fonctionnement de base, et les droits plus larges se demandent au moment où une opération en a besoin. Un serveur qui publie tous ses droits d'emblée augmente les dégâts en cas de vol de jeton. Détails dans sécurité des serveurs MCP.

Côté utilisateur : les connecteurs de Claude

Pour l'utilisateur, tout cela se résume à coller une adresse et à se connecter. Dans Claude, un serveur distant s'ajoute comme connecteur personnalisé (Settings > Connectors, « Add custom connector »). D'après le centre d'aide d'Anthropic, relevé le 15/11/2026 :

• les connecteurs personnalisés sont proposés sur les offres Free, Pro, Max, Ultra, Team et Enterprise ; l'offre Free est limitée à un connecteur personnalisé ;
• sur Team, seuls les propriétaires (Owners et Primary Owners) les ajoutent ; les membres s'y connectent ensuite chacun de leur côté ;
• le serveur doit être joignable publiquement en HTTPS sur le port 443 ;
• côté OAuth, l'administrateur peut utiliser l'identité publiée de Claude (option recommandée), l'enregistrement automatique ou son propre client OAuth ; une clé fixe peut aussi passer par des en-têtes de requête.

Pour une organisation

Si chaque salarié doit autoriser chaque serveur un par un, la gestion devient vite lourde. L'extension « Enterprise-Managed Authorization » confie la décision au fournisseur d'identité de l'entreprise : voir MCP en entreprise.