Authentification et autorisation MCP : principales différences expliquées

Lorsqu'un agent IA se connecte à un serveur MCP, il doit vérifier son identité (authentification MCP) et définir les fonctions qu'il est autorisé à exécuter une fois l'accès accordé (autorisation MCP) afin de garantir la sécurité du client MCP et du système. Il est essentiel de faire la différence entre ces deux types de contrôles d'accès.

Lorsque les contrôles de sécurité sont utilisés de manière incorrecte ou interchangeable, des failles de sécurité apparaissent qui constituent des défis pour les utilisateurs et les administrateurs des systèmes traditionnels. Dans les environnements MCP, l'absence de contrôles de sécurité définis crée des risques plus graves que dans les systèmes traditionnels.

Ce guide fournit des descriptions détaillées de l'authentification et de l'autorisation MCP, de leur fonctionnement au sein de l'écosystème des protocoles de contexte du modèle et des éléments nécessaires à la mise en œuvre de ces concepts pour une adoption réussie par les entreprises dans un environnement de production en direct.

Qu'est-ce que l'authentification MCP ?

L'authentification MCP est le premier point de vérification entre un client MCP et un serveur MCP. Avant d'exécuter une commande via des outils, le client doit s'identifier et s'authentifier pour établir la confiance. Pour s'authentifier auprès de serveurs MCP distants (HTTP/HTTPS), le mécanisme d'autorisation le plus couramment utilisé est OAuth 2.1 avec PKCE.

Lorsqu'un agent s'authentifie avec succès auprès d'un serveur d'autorisation, le client échange des informations d'identification contre un jeton OAuth, souvent par le biais d'un échange de jetons initié au point de terminaison des métadonnées. Le serveur MCP n'autorisera pas de connexion à moins que l'agent ne dispose d'un jeton OAuth valide.

Contrairement aux méthodes de connexion standard, les serveurs MCP locaux qui se connectent via le transport STDIO ne nécessitent pas d'agent pour s'authentifier. Ils utilisent plutôt la limite de confiance du processus hôte, souvent configurée via des variables d'environnement dans les cas d'utilisation de base.

Les types d'informations d'identification les plus couramment utilisés sont les suivants :

• Jetons d'accès OAuth 2.1 : De courte durée (généralement une heure) et d'une portée limitée, il s'agit du type d'identification recommandé pour un accès sécurisé dans les systèmes de production.
• Clés d'API : Facile à utiliser, sans expiration ni contrôle d'accès précis ; ce type d'identification est considéré comme risqué lors de la gestion de nombreux utilisateurs sur des systèmes externes.
• JWT : Les déclarations concernant l'identité des utilisateurs, telles que l'utilisateur, le rôle et le locataire, sont intégrées au JWT, bien qu'elles soient complexes en raison de la nécessité d'une logique d'autorisation supplémentaire.
  

Depuis la mise à jour de juin 2025 de la spécification MCP, les serveurs sont désormais traités comme des serveurs de ressources OAuth et valident les jetons mais n'émettent pas de jetons aux utilisateurs. Au lieu de cela, la responsabilité de l'émission des jetons a été transférée à des fournisseurs d'identité externes tels qu'Okta, Azure AD et Auth0.

Cela crée un point unique d'authentification MCP et intègre le SSO, le MFA et l'auditabilité au niveau de l'identité dans l'écosystème MCP sans nécessiter d'implémentations personnalisées.

Qu'est-ce que l'autorisation MCP ?

L'authentification établit l'identité du client, tandis que l'autorisation MCP détermine les capacités du client.

L'autorisation régit le contrôle d'accès à un niveau très détaillé, en fournissant des restrictions quant aux outils qui peuvent être invoqués, aux données auxquelles il est possible d'accéder et aux conditions dans lesquelles ces actions peuvent être entreprises. L'autorisation est évaluée en continu, plutôt que comme une évaluation ponctuelle, pour chaque appel d'outil.

Dans les systèmes MCP, l'autorisation utilise généralement une approche à plusieurs niveaux. Les couches d'autorisation présentes dans les systèmes MCP incluent :

• Autorisations basées sur la portée : Autorisations définies lors de l'émission du jeton qui établissent les limites extérieures de tous les champs d'application OAuth possibles et des actions entreprises.
• Contrôle d'accès basé sur les rôles (RBAC) : Mappage des autorisations aux rôles afin de garantir que tous les utilisateurs et tous les agents d'IA accédant au même rôle disposent des mêmes droits d'accès à ces ressources.
• Contrôles au niveau des ressources : Restreindre l'accès sécurisé à des ensembles de données, à des outils ou à des environnements spécifiques.
• Politiques contextuelles : Appliquer des conditions d'exécution telles que l'heure, les modèles de demande ou les signaux de risque à ce qui précède

La dernière couche d'autorisation représente l'aspect le plus intéressant du cadre d'autorisation MCP moderne. Un jeton qui a été autorisé à appeler la méthode read_file à 9 heures du matin peut également se voir refuser la possibilité d'appeler la même méthode à 2 heures du matin sur la base d'une autre politique applicable aux deux premiers paramètres de référence.

Authentification et autorisation dans MCP : les principales différences

Bien que l'authentification et l'autorisation soient parfois confondues, elles représentent une approche à deux niveaux dans le contexte du MCP. Les deux zones offrent différents niveaux de contrôle d'accès, et les modes de défaillance de chacune diffèrent en conséquence.

Si l'authentification est correcte mais que l'autorisation appropriée n'est pas appliquée, chaque client authentifié devient un superutilisateur.

Les modes de défaillance s'opposent souvent les uns aux autres :

• Une authentification MCP faible permet de transmettre des identités incorrectes.
• Une autorisation MCP faible permet à des identités correctes d'effectuer des actions excessives.

Les systèmes MCP de type production nécessitent les deux types de contrôle appliqués indépendamment

Comment l'authentification et l'autorisation MCP fonctionnent-elles ensemble dans un véritable flux MCP ?

Vous trouverez ci-dessous un exemple concret d'une séquence d'étapes qui se produisent lorsqu'un agent contacte un serveur MCP distant. Cela aboutira à un appel d'outil réussi ou entraînera un échec.

Étape 1 : L'agent tente de se connecter au serveur MCP en tant que client MCP. Le serveur MCP ne reconnaît pas que le client possède une session ouverte. Il renvoie donc une réponse 401 Unauthorized ainsi que les métadonnées du serveur d'autorisation pointant vers le serveur d'autorisation.

Étape 2 : L'agent envoie une demande de redirection au serveur d'autorisation (Okta, Azure AD ou Auth0), où le flux OAuth avec PKCE est terminé. L'utilisateur ou le service s'authentifie et accepte les étendues OAuth demandées, en recevant un code d'autorisation.

Étape 3 : Après avoir reçu un code d'autorisation du serveur d'autorisation, l'agent utilise le flux de code d'autorisation pour obtenir un jeton d'accès depuis le point de terminaison du jeton. Un jeton d'accès fournit à l'agent un accès sécurisé temporaire tout en confirmant l'authenticité de la communication et en limitant l'agent aux champs d'application OAuth approuvés réclamés au nom de l'application demandeuse.

Étape 4 : Lors de l'obtention d'un jeton d'accès, l'agent communique avec MCP en incluant le jeton d'accès dans l'en-tête Authorization en tant que jeton porteur. Le serveur MCP valide la signature, la date d'expiration et l'entité émettrice du jeton par rapport aux clés publiques du serveur d'autorisation lors de la validation du jeton afin de confirmer l'identité de l'agent.

Étape 5 : Lorsque l'agent appelle le serveur MCP avec la portée tools:read, le serveur MCP vérifie d'abord si les étendues des jetons d'accès correspondent à l'action demandée. Comme la section tools : read scope n'autorise pas les actions destructrices, le serveur MCP renvoie un code de réponse interdit 403 et enregistre le refus d'accès dans le cadre du flux d'autorisation.

Étape 6 : Pour empêcher les flux de travail d'automatisation non autorisés d'atteindre des serveurs mal configurés, un moteur de politiques ou une passerelle MCP est placé devant le serveur MCP. Le moteur de politiques vérifie que chaque appel d'outil ne dépasse aucune limite de débit et ne viole aucune politique contextuelle ou aucune règle basée sur la portée avant d'autoriser la transmission de la demande vers la logique du serveur.

Quelles sont les erreurs des équipes en matière d'authentification et d'autorisation MCP ?

Même les équipes qui utilisent les deux couches les utilisent souvent à mauvais escient.

• Traiter un jeton valide comme une autorisation générale : Certaines entreprises utilisent des jetons valides pour l'accès global. Les développeurs créent donc généralement de nouveaux jetons qui leur confèrent des droits qu'ils ne devraient pas avoir. Grâce à ces jetons, ils les utilisent pour accéder aux ressources de la base de données de production, soit au niveau du développeur uniquement, soit en utilisant la sécurité d'authentification par jeton pour accéder aux ressources de la base de données par erreur lors de leur création initiale de manière à accorder ces droits au développeur.
• Autorisation ignorée pour les serveurs MCP internes : Une limite de réseau à elle seule ne garantit pas que vous ne pourrez pas y accéder. Une personne disposant d'un accès interne peut accéder à toutes les ressources internes sur le serveur d'applications interne de traitement des commandes client.
• Clés d'API statiques utilisées sans pile d'autorisations appropriée : Les clés d'API statiques peuvent ne pas avoir de portée, d'expiration ou de mécanisme de révocation OAuth. Si une clé d'API statique est publiée dans un fichier journal ou un référentiel, la seule solution consiste à alterner les informations d'identification, ce qui perturbe les opérations à grande échelle.
• S'appuyer uniquement sur les scopes OAuth sans RBAC au niveau de la passerelle : Les étendues OAuth définissent ce que le jeton peut effectuer au cours d'une session, tandis que les rôles définissent ce que la personne est chargée d'effectuer. Si le RBAC n'est pas appliqué au niveau de la passerelle, un pipeline automatisé aura le même accès qu'un ingénieur humain.
• Ne pas réévaluer l'accès une fois que l'autorisation a été accordée au début d'une session : Lorsqu'un agent IA est autorisé à exercer ses fonctions au début de la session, si le rôle de l'agent change au cours de la session, toutes les autorisations accordées avant cette modification continueront de s'appliquer pendant toute la période. Il s'agit d'un risque important dans les systèmes agentiques où des agents autonomes peuvent fonctionner pendant des sessions prolongées.

Quelles sont les exigences de la mise en œuvre de l'authentification et de l'autorisation MCP en entreprise ?

Il n'est pas possible pour les équipes ou les implémentations de serveurs individuels de gérer seules l'authentification MCP et l'autorisation MCP à grande échelle. Ils devraient plutôt être mis en œuvre sur plusieurs serveurs au niveau de la plate-forme.

Pour ce faire, les éléments suivants doivent être pris en compte :

• Gestion centralisée des identités via un fournisseur d'identité : Toutes les demandes d'authentification MCP sur les serveurs MCP doivent passer par le même fournisseur d'identité, qu'il s'agisse d'Okta, d'Azure AD ou d'Auth0. La configuration d'authentification distribuée n'évoluera pas et fragmentera les pistes d'audit.
• Jetons à portée de courte durée de vie appliqués par l'infrastructure : Tous les serveurs MCP doivent appliquer des jetons d'accès de courte durée avec des étendues OAuth définies via l'infrastructure. L'équipe ne peut pas définir correctement l'expiration ou la portée des jetons pour chaque déploiement, mais l'infrastructure les appliquera de manière cohérente.
• RBAC par serveur et rôle avec propagation immédiate des politiques : Lorsqu'une équipe modifie le rôle d'un utilisateur ou d'un membre de l'équipe, la modification doit se propager immédiatement à tous les serveurs et entrer en vigueur sans attendre le prochain cycle de déploiement.
• Pistes d'audit combinées uniques pour les journaux d'accès et d'autorisation : Les journaux d'accès et les journaux d'autorisation MCP sont requis par différentes équipes. Les deux équipes ont besoin d'accéder à des pistes d'audit combinées à l'aide d'un identifiant de demande commun pour les enquêtes futures.
• Application du contrôle d'accès à la passerelle distincte du code de l'application : Si la politique d'application est stockée sur le serveur et que celui-ci n'est pas correctement déployé, la stratégie d'application peut être désactivée sans détection. Cependant, la passerelle MCP appliquera à la fois les contrôles de portée OAuth et les limites de débit, quel que soit le comportement de l'application.

Comment TrueFoundry applique l'authentification et l'autorisation MCP au niveau de la plate-forme ?

TrueFoundry considère l'authentification et l'autorisation MCP comme des concepts fondamentaux de sa plateforme, et non comme des tâches à effectuer par des applications individuelles.

• Intégration d'Enterprise IdP prête à l'emploi : TrueFoundry permet aux entreprises de connecter leur fournisseur d'identité d'entreprise via Okta, Azure AD ou tout autre serveur d'autorisation OAuth prenant en charge OAuth 2.0. Les jetons d'authentification sont fournis et la vérification de l'identité s'effectue via l'infrastructure d'identité existante de chaque organisation. Les organisations n'ont pas besoin de créer ou de gérer un serveur d'autorisation supplémentaire pour compléter leurs demandes.
• Le RBAC par serveur est appliqué à la passerelle, et non à l'application : En appliquant le contrôle d'accès à la passerelle MCP avant qu'une demande n'atteigne la logique d'application du serveur MCP, TrueFoundry garantit que les politiques d'accès sont appliquées sur plusieurs instances MCP, quelle que soit la manière dont chaque instance d'application est développée ou déployée.
• Accès délimité qui associe les rôles organisationnels aux autorisations des outils : TrueFoundry prend en charge la définition de la portée des autorisations MCP, un groupe tel que Finance étant affecté à un ensemble d'outils et un autre groupe, tel que Support, étant affecté à un autre. Un agent financier et un agent de support peuvent accéder à la même infrastructure MCP tout en disposant d'autorisations d'outils distinctes. Le mappage entre les rôles et les étendues OAuth est défini une fois sur la plateforme et s'applique à toutes les instances.
• Piste d'audit unifiée au sein de votre VPC : TrueFoundry fournit une piste d'audit consolidée unique au sein du VPC du client pour les événements associés à la validation des jetons et aux appels d'outils. Les équipes de sécurité ont accès à une piste d'audit complète et chronologique. Tous les événements de validation de jetons et d'invocation d'outils incluent un identifiant de demande uniforme, ce qui permet d'identifier facilement les événements liés à un utilisateur spécifique à travers de grands modèles de langage et des outils externes.
• Configuration par défaut de la plateforme, et non par équipe : Les fonctionnalités d'authentification MCP et d'autorisation MCP sont activées par défaut pour toutes les organisations. Ces politiques sont toujours héritées par les applications MCP lors du déploiement d'agents IA, de sorte que les équipes n'ont pas besoin de créer leurs propres politiques ou de mettre en œuvre une authentification appropriée sur chaque nouveau serveur MCP.

TrueFoundry fournit l'authentification et l'autorisation MCP en tant que fonctionnalités de base de la plate-forme, plutôt que comme une charge de configuration individuelle pour les organisations utilisant ses outils.

Questions fréquemment posées

Qu'est-ce que l'authentification MCP et l'autorisation MCP ?

L'authentification MCP et l'autorisation MCP sont deux concepts de sécurité distincts. L'authentification MCP confirme l'identité du client MCP avant que l'accès ne soit accordé, à l'aide de jetons OAuth ou de clés API. L'autorisation MCP détermine ce que le client authentifié peut faire via les étendues OAuth et le RBAC. Les deux sont nécessaires dans tout déploiement de serveur MCP de production afin de prévenir les risques de sécurité liés à un accès non autorisé.

Quelle est la différence entre l'authentification et l'autorisation dans MCP ?

L'authentification MCP se produit une fois lors de la connexion et utilise le flux de code d'autorisation ou le flux d'informations d'identification du client pour vérifier l'identité. L'autorisation MCP est évaluée à chaque appel d'outil pendant la connexion, en appliquant les étendues OAuth et les règles RBAC à chaque demande faite par l'agent IA via le serveur MCP.

Pouvez-vous obtenir une autorisation MCP sans authentification ?

Aucune autorisation MCP significative n'est possible sans authentification MCP, car il n'existe aucune identité authentifiée par rapport à laquelle évaluer les autorisations. Sans authentification appropriée pour établir l'identité, le serveur d'autorisation n'a aucune base pour émettre des jetons d'accès ou appliquer une logique d'autorisation aux demandes entrantes provenant d'agents IA ou d'agents autonomes.

Qu'est-ce qui vient en premier, l'authentification MCP ou l'autorisation MCP ?

L'authentification MCP passe toujours en premier. Le flux d'autorisation établit l'identité du client MCP auprès du serveur d'autorisation. L'autorisation MCP se produit ensuite pour chaque demande suivante une fois que l'authentification du client est terminée et que des jetons d'accès avec des étendues OAuth définies ont été émis.

TrueFoundry prend-il en charge le « Bring-your-own IdP » ?

Oui TrueFoundry s'intègre à tout fournisseur d'identité ou serveur d'autorisation OAuth conforme à la norme OAuth 2.0, ce qui permet aux entreprises de réutiliser leur infrastructure d'identité existante. Cela inclut la prise en charge de fournisseurs d'identité externes tels qu'Okta et Azure AD, permettant une authentification MCP centralisée sur tous les serveurs MCP sans créer de configuration de serveur d'autorisation distincte.