L'authentification MCP expliquée : comment elle fonctionne et pourquoi elle est importante

L'authentification et l'autorisation MCP n'ont pas toujours été aussi sécurisées qu'aujourd'hui. Lorsque MCP a commencé à être déployé, l'authentification s'effectuait généralement via des clés d'API, qui étaient souvent incluses dans un fichier de configuration ou en tant que variables d'environnement, permettant ainsi un accès statique, partagé et non limité. Si cette clé était divulguée, elle accorderait à un utilisateur malveillant un accès complet, sans aucun moyen de suivre ou de contrôler ce qui a été fait.

La spécification MCP a évolué rapidement pour résoudre ce problème :

• mars 2025: OAuth 2.1 a été défini comme la norme pour authentifier une application ou un utilisateur auprès d'une API.
• juin 2025: les serveurs MCP ont été redéfinis en tant que serveurs de ressources OAuth, et la possibilité d'émettre des jetons a été transférée à des fournisseurs d'identité externes.
• novembre 2025: PKCE est devenu obligatoire pour toutes les applications côté client, et le CIMD a été défini comme un moyen d'identifier de manière unique chaque instance client.

En moins d'un an, la méthode d'authentification MCP est passée des secrets statiques à un modèle compatible avec les systèmes d'identité d'entreprise modernes.

Ce guide décrit ce qu'est l'authentification MCP, comment elle fonctionne, les approches possibles pour l'implémenter, les domaines dans lesquels les implémentations échouent et comment l'implémenter correctement à grande échelle.

Qu'est-ce que l'authentification MCP ?

L'authentification MCP est le processus par lequel un serveur MCP vérifie l'identité d'un demandeur avant d'exécuter un outil.

Sans authentification MCP, tout client MCP susceptible d'accéder à un serveur MCP pourrait invoquer ses outils, indépendamment de l'identité, du rôle ou de l'intention de ce client. Si les outils invoqués établissent une connexion avec des systèmes externes critiques tels que des CRM, des bases de données ou des services cloud, cela créerait un chemin illimité vers la production de données sensibles.

Il ne s'agit pas d'un risque théorique. Une vulnérabilité CVSS 9.6 dans le package mcp-remote a permis à des serveurs MCP malveillants d'exploiter le flux OAuth du package pour exécuter à distance des commandes arbitraires du système d'exploitation, ce qui a eu un impact sur des centaines de milliers de téléchargements.

L'authentification MCP est effectuée via la couche de transport avant l'exécution de l'outil. Le mode d'exécution dépend de la manière dont le serveur MCP est déployé :

• Transport en studio (serveurs locaux) : s'exécute en tant que processus local ; l'authentification MCP peut utiliser des variables d'environnement ou des informations d'identification système extérieures à MCP.
• HTTP diffusable (serveurs distants) : fonctionne sur le réseau sans aucune confiance partagée entre le client et le serveur MCP. L'authentification MCP s'effectue à l'aide d'OAuth 2.1 avec des jetons d'accès attachés à chaque demande.

Dans la pratique :

• Développement local : des certifications fondées sur l'environnement peuvent être suffisantes.
• Systèmes de production à distance : OAuth 2.1 est requis pour une authentification correcte.

Les trois types d'authentification MCP

Méthodes d'authentification utilisées dans différents déploiements MCP en fonction de l'environnement et de la tolérance au risque

Clés d'API et jetons statiques

Il s'agit d'une méthode simple qui permet de transmettre une clé prédéfinie à chaque demande.

Autorisation : Bearer sk-xxxx

Quand ça marche :

• Dans le cadre du développement local, et par un outil interne fonctionnant dans les limites d'un réseau bien défini.

Restrictions :

• Les jetons statiques n'ont pas d'expiration
• Les jetons statiques n'ont aucune identité d'utilisateur
• Aucune autorisation granulaire
• Les jetons statiques peuvent être divulgués via les journaux ou le contrôle de version, ce qui est très risqué.
• Lorsque des jetons statiques sont exposés, le contrôle d'accès complet au système associé reste actif jusqu'à ce qu'il soit désactivé manuellement

OAuth 2.1 avec PKCE (standard pour les serveurs MCP distants)

À compter de la mise à jour des spécifications MCP de mars 2025, la norme de sécurisation des serveurs MCP distants via l'authentification MCP est OAuth 2.1 avec PKCE. Au lieu d'informations d'identification statiques, cette approche utilise un flux d'autorisation sécurisé basé sur des jetons qui permet le protocole HTTP Streamable.

Comment ça fonctionne :

• Découverte de métadonnées : Le client MCP tente de découvrir les métadonnées requises du serveur d'autorisation depuis le serveur sans jeton d'accès et reçoit une réponse 401. Le document de métadonnées des ressources protégées indique au client à quel serveur d'autorisation se connecter et quelles étendues requises sont disponibles.
• Enregistrement des clients : Le client MCP s'enregistre auprès du serveur d'autorisation. La méthode par défaut depuis novembre 2025 est le protocole CIMD. Le client publie les métadonnées de son identifiant client sur une URL publique qu'il contrôle, et le serveur d'autorisation effectue la validation des informations du client lors de l'exécution.
• Code d'autorisation : Le client ouvre le navigateur de l'utilisateur, lui demande de se connecter et de donner son consentement, et reçoit un code d'autorisation du serveur d'autorisation pour agir en son nom.
• Émission de jetons d'accès : Le client échange le code d'autorisation en utilisant le flux de code d'autorisation pour un jeton d'accès limité à la ressource demandée, et inclut ce jeton à chaque demande MCP.

Pourquoi PKCE est important :

• PKCE protège contre les attaques d'interception en s'assurant que l'utilisateur effectuant l'authentification MCP est bien la même personne qui l'a initiée.
• Le PKCE est requis pour tous les clients MCP à partir de novembre 2025 conformément à la spécification MCP actuelle.

Informations d'identification basées sur l'environnement (serveurs STDIO)

Les serveurs MCP locaux héritent des informations d'identification de leur propre environnement d'exécution.

Avantages :

• Facile à configurer sans flux d'autorisation externe.

Inconvénients :

• Les informations d'identification sont accessibles à tous les processus pouvant accéder au système MCP, ce qui crée des risques pour toutes les sources de données.
• Difficile à gérer entre plusieurs personnes ou équipes sans logique d'autorisation centralisée.
• Pas de gouvernance ni de contrôle d'accès centralisés.

Dans les environnements de production, vous devez récupérer vos informations d'identification de manière dynamique à l'aide d'un coffre-fort sécurisé au lieu de les stocker en texte brut.

Comment fonctionne l'authentification MCP OAuth 2.1 étape par étape

Lorsqu'un client MCP se connecte à un serveur MCP protégé, le flux MCP suivant se produit :

• Étape 1 — Le client se connecte, le serveur rejette : Le client MCP tente une demande sans jeton. Le serveur répond par une erreur 401 Unauthorized et un pointeur vers l'URL des métadonnées de sa ressource protégée dans le cadre de la découverte du serveur d'autorisation.
• Étape 2 — Le client récupère les métadonnées : Le point de terminaison des métadonnées spécifie le serveur d'autorisation à utiliser, les étendues OAuth disponibles et l'emplacement du point de terminaison du jeton.
• Étape 3 — Le client s'enregistre et démarre le flux OAuth : Le client s'identifie à l'aide de CIMD et de son document de métadonnées d'identifiant client, crée un vérificateur de code PKCE et un challenge de code, puis redirige le navigateur de l'utilisateur vers la page de connexion du serveur d'autorisation.
• Étape 4 — L'utilisateur s'authentifie et reçoit le code d'autorisation : L'utilisateur se connecte et donne son consentement. Le serveur d'autorisation renvoie un code d'autorisation que le client peut échanger à l'aide du vérificateur de code d'origine contre un jeton d'accès limité et de courte durée.
• Étape 5 — Le client appelle le serveur MCP avec le jeton porteur : Chaque demande MCP inclut le jeton d'accès dans l'en-tête Authorization Bearer. Le serveur MCP valide les champs d'émission, d'audience, d'expiration et d'OAuth. Si le jeton d'accès comporte des étendues requises insuffisantes, le serveur répond par un 403 et demande une autorisation utilisateur supplémentaire, une fonctionnalité introduite en novembre 2025.

Où l'authentification MCP ne fonctionne toujours pas ?

De nombreux déploiements présentent de graves risques de sécurité MCP en raison d'une implémentation incorrecte de l'authentification et des autorisations MCP, même lors de l'utilisation d'OAuth.

• Jetons statiques dans les fichiers de configuration : Clés d'API validées dans des référentiels Git, partagées dans des fichiers mcp.json ou .env et oubliées. Un seul identifiant client OAuth compromis fournit un accès illimité et n'expire jamais, créant ainsi une source persistante d'accès non autorisé.
• Portées OAuth surautorisées : Les utilisateurs demandent un grand nombre d'étendues OAuth lors de la configuration, mais ne les limitent pas lors de l'exécution de l'application. Un agent d'IA configuré en lecture seule doit être stocké avec un jeton d'accès à portée de lecture plutôt qu'un jeton de lecture/écriture/suppression.
• Aucune rotation des jetons dans les déploiements autogérés : Tokens OAuth à longue durée de vie émis pour des déploiements autogérés sans processus de rotation. Si un jeton est compromis, il reste fonctionnel en tant que jeton porteur valide jusqu'à ce que quelqu'un le désactive manuellement.
• Aucune piste d'audit pour les appels d'outils : Lorsqu'un jeton est émis et que des outils externes sont accessibles, aucun enregistrement n'indique qui a effectué la demande MCP d'origine, ce qui rend impossible l'investigation des causes profondes pour les membres de l'équipe de sécurité.

La plupart de ces problèmes sont résolus lorsque les organisations migrent des clés statiques vers OAuth 2.1, qui permet d'activer des jetons d'accès de courte durée, des étendues OAuth étendues et une journalisation centralisée des audits via le serveur d'autorisation.

Les exigences d'authentification MCP des entreprises et la manière dont TrueFoundry les résout

TrueFoundry simplifie la gestion de multiples formes d'authentification et d'autorisation MCP au sein des différentes équipes et applique des contrôles uniformes à tous les serveurs MCP via une seule couche de passerelle MCP.

Réservez une démo pour comprendre comment MCP gère l'authentification au niveau de l'infrastructure

Questions fréquemment posées

Qu'est-ce que l'authentification MCP ? 

L'authentification MCP est le processus de vérification de l'identité d'une entité qui tente de se connecter à un serveur MCP, à l'aide de jetons OAuth, de clés d'API ou de variables d'environnement en fonction du contexte de déploiement. Il permet uniquement aux agents IA vérifiés et aux clients MCP d'accéder aux outils et aux services externes, constituant ainsi la première couche d'authentification et d'autorisation MCP dans tout système de production.

Le MCP nécessite-t-il OAuth ? 

Pas dans tous les cas. Un serveur de transport STDIO local peut ne pas implémenter de flux OAuth formel. Cependant, tout serveur MCP distant gérant des données sensibles liées à la production ou des outils externes doit utiliser OAuth 2.1 avec PKCE comme mécanisme d'autorisation standard selon la spécification MCP actuelle pour une authentification MCP et une application des autorisations appropriées.

Le MCP est-il doté d'une authentification ? 

MCP prend en charge l'authentification et l'autorisation MCP, et la méthode dépend de l'environnement du serveur. Les serveurs distants utilisent OAuth 2.1 PKCE comme flux d'autorisation standard. Les serveurs de transport STDIO locaux s'authentifient à l'aide des informations d'identification des variables d'environnement ou du processus hôte. La spécification MCP a officiellement mandaté OAuth 2.1 comme norme pour les déploiements à distance à partir de mars 2025.

Quels sont les types d'authentification MCP ? 

Trois méthodes courantes existent pour l'authentification et l'autorisation MCP : des clés d'API statiques pour les cas d'utilisation internes ou de développement, OAuth 2.1 avec PKCE pour tous les déploiements de serveurs MCP distants comme l'exige la spécification MCP, et des informations d'identification basées sur l'environnement via des variables d'environnement pour les serveurs de transport STDIO locaux où un flux d'enregistrement des clients OAuth formel n'est pas requis.

Comment fonctionne l'authentification MCP ? 

Lorsqu'un client MCP se connecte à un serveur MCP protégé, le serveur renvoie un 401 avec un pointeur vers son document de métadonnées de ressource protégé. Le client effectue la découverte du serveur d'autorisation, s'enregistre à l'aide de CIMD, complète le flux de code d'autorisation avec PKCE et reçoit un jeton d'accès limité. Ce jeton est inclus dans chaque demande entrante de validation de jeton avant qu'un appel d'outil ne soit autorisé.

Comment TrueFoundry gère-t-il l'authentification MCP ? 

Grâce à la passerelle MCP, TrueFoundry centralise l'authentification et l'autorisation MCP en s'intégrant aux fournisseurs d'identité d'entreprise et en gérant l'émission, la rotation et la validation automatisées des jetons d'accès. Les étendues OAuth et les politiques RBAC sont appliquées au niveau de la passerelle sur tous les serveurs MCP, avec des journaux d'audit structurés conservés dans le VPC du client pour assurer la conformité des agents IA et des services externes.