L'authentification est-elle obligatoire dans MCP ?

Non. L'autorisation est optionnelle dans la spécification MCP. Les serveurs distants HTTP devraient l'implémenter. Les serveurs locaux STDIO récupèrent leurs identifiants dans l'environnement.

Quelle version d'OAuth MCP utilise-t-il ?

L'autorisation MCP repose sur le brouillon OAuth 2.1, avec PKCE, les métadonnées de ressource protégée (RFC 9728) et les indicateurs de ressource (RFC 8707).

Qu'est-ce que le token passthrough dans MCP ?

Un serveur MCP qui accepte un jeton qui ne lui était pas destiné et le transmet à une autre API. La spécification MCP l'interdit : un serveur n'accepte que les jetons émis pour lui.

Quelle différence entre une 401 et une 403 dans MCP ?

Une 401 signale un jeton absent ou invalide. Une 403 insufficient_scope signale un jeton valide auquel il manque un scope ; l'en-tête WWW-Authenticate indique le scope requis et le client peut le demander (step-up).

Les serveurs MCP locaux sont-ils plus sûrs ?

Pas forcément. Ils évitent l'exposition réseau, mais s'exécutent avec les droits de l'utilisateur et reposent souvent sur des clés statiques stockées sur le poste.

OAuth protège-t-il de l'injection de prompt ?

Non. OAuth contrôle qui peut appeler un serveur et avec quels scopes. L'empoisonnement d'outils et l'injection de prompt demandent d'autres mesures : revue des outils, scopes limités, sorties d'outils traitées comme non fiables.

Sécurité MCP : authentification, OAuth et autorisation

Pourquoi un serveur MCP est un sujet d'identité

Pour lire une boîte mail ou interroger un CRM, un serveur MCP détient un identifiant : clé API, jeton OAuth ou compte de service. Cet identifiant est une identité non humaine. Quiconque contrôle le serveur, ou le manipule, peut utiliser ces droits. La sécurité MCP relève donc surtout de la sécurité des identités : ce que l'identifiant permet d'atteindre, qui en est responsable, quand il a servi pour la dernière fois.

Serveurs MCP locaux (STDIO) ou distants (HTTP)

Locaux (STDIO) : le serveur tourne comme un processus sur le poste de l'utilisateur. La spécification MCP indique que les implémentations STDIO NE DEVRAIENT PAS utiliser le flux d'autorisation MCP et doivent récupérer leurs identifiants dans l'environnement. En pratique, ce sont souvent des clés dans des variables d'environnement ou des fichiers de configuration : protégez le poste et ces fichiers.
Distants (HTTP) : le serveur est un service réseau. L'autorisation est optionnelle dans MCP, mais les implémentations HTTP DEVRAIENT suivre la spécification d'autorisation. C'est là qu'OAuth s'applique.

Comment fonctionne l'autorisation MCP (OAuth 2.1 en 6 étapes)

La spécification d'autorisation MCP s'appuie sur le brouillon OAuth 2.1. Le serveur MCP joue le rôle de serveur de ressources OAuth 2.1.

1Challenge. En général, le client appelle sans jeton et reçoit une 401 avec un en-tête WWW-Authenticate qui pointe vers les métadonnées du serveur.
2Découverte. Les serveurs MCP DOIVENT publier les métadonnées de ressource protégée OAuth 2.0 (RFC 9728), qui désignent le serveur d'autorisation. Les clients DOIVENT les utiliser pour le trouver.
3Enregistrement. Le client obtient un identifiant client : de préférence via un Client ID Metadata Document, ou par pré-enregistrement. L'enregistrement dynamique (Dynamic Client Registration) est déprécié et conservé pour compatibilité.
4Autorisation. L'utilisateur se connecte. Le client utilise PKCE et DOIT envoyer le paramètre resource (RFC 8707) qui désigne le serveur MCP. Il vérifie la valeur iss de la réponse (RFC 9207).
5Utilisation du jeton. Le jeton passe dans l'en-tête Authorization: Bearer à chaque requête, jamais dans l'URL.
6Validation. Le serveur DOIT vérifier que le jeton a été émis pour lui (audience). Jeton absent ou invalide : 401. Jeton valide sans le bon scope : 403 insufficient_scope, et le client peut demander un scope supplémentaire (step-up).

Les principaux risques de sécurité MCP

Le projet MCP les détaille dans ses bonnes pratiques de sécurité :

Transmission de jeton (token passthrough) : un serveur accepte le jeton d'un client sans vérifier qu'il lui était destiné, puis le transmet à une API en aval. La spécification l'interdit.
Adjoint confus (confused deputy) : un serveur MCP proxy qui utilise un identifiant client statique auprès d'un serveur d'autorisation tiers peut permettre à un client malveillant d'obtenir un code d'autorisation sans réel consentement de l'utilisateur.
Scopes trop larges : des scopes comme files:* ou admin:* aggravent l'impact de tout jeton volé.
Compromission d'un serveur local : un serveur local s'exécute avec les droits de l'utilisateur et peut lire fichiers et clés du poste.
Clés statiques dans des fichiers de configuration : des clés de longue durée finissent copiées, synchronisées, divulguées.
Serveurs sans responsable : un serveur de test garde des identifiants actifs après le départ de son créateur.
Empoisonnement d'outils et injection de prompt : des descriptions d'outils ou des sorties malveillantes poussent le modèle à abuser de ses accès. OAuth n'empêche pas cela.

Checklist de sécurité des serveurs MCP

1Tenez un inventaire de tous les serveurs MCP, locaux et distants, avec un responsable nommé.
2Identifiez l'identifiant derrière chaque serveur et ce qu'il permet d'atteindre.
3Pour les serveurs distants, implémentez l'autorisation MCP : OAuth 2.1, PKCE, métadonnées de ressource protégée.
4Pour les serveurs locaux, sortez les identifiants des fichiers de configuration partagés et du contrôle de version.
5Vérifiez l'audience du jeton côté serveur. Ne transmettez jamais les jetons des clients.
6Demandez des scopes minimaux ; utilisez le step-up pour les actions sensibles.
7Préférez des jetons de courte durée aux clés statiques ; gardez les secrets restants dans un coffre-fort.
8Envoyez les jetons uniquement dans l'en-tête Authorization, via TLS.
9Relisez les descriptions d'outils avant installation ; traitez les sorties d'outils comme non fiables.
10Revoyez l'activité régulièrement et supprimez serveurs, clés et autorisations OAuth inutilisés.

La place de Cydenti

Cydenti est une plateforme de sécurité des identités non humaines, pas une passerelle MCP. Il ne s'insère pas dans les sessions MCP, n'émet pas d'identifiants d'exécution et ne fait pas de rotation de secrets. Il lit Microsoft 365 / Entra ID, Google Workspace et Salesforce via des API en lecture seule, et peut montrer les comptes de service et applications OAuth qu'utilisent les serveurs MCP, lorsque ces identités sont visibles dans l'une de ces applications. L'Identity Graph et l'analyse du rayon d'impact montrent ce que chaque identité peut atteindre, et la remédiation des droits excessifs ou inutilisés s'exécute automatiquement, selon les politiques que vous définissez. Les vues MCP dédiées sont en préversion : voir sécurité MCP. Cydenti complète vos outils IAM, PAM et passerelles.

Sécurité des serveurs MCP : authentification, OAuth et contrôle d'accès