Voici ce que personne n’explique clairement au sujet de l’autorisation MCP : il ne s’agit pas d’une couche de sécurité personnalisée inventée par Anthropic. C’est OAuth 2.1, appliqué à un nouveau contexte précis, avec un ensemble d’attributions de rôles définies avec précision par la spécification. La confusion ne porte pas sur la technologie. Elle concerne le rôle de chaque élément et l’emplacement de la frontière entre le composant qui émet les jetons et celui qui les applique.
J’ai vu cette confusion provoquer des incidents en production selon un schéma désormais presque prévisible. Une équipe connecte un serveur MCP, confirme que le client peut s’y connecter et le déclare « autorisé ». Trois mois plus tard, quelqu’un demande pourquoi un agent peut appeler un outil d’écriture qu’il n’était jamais censé utiliser. La réponse est généralement que le jeton a été émis correctement, mais que personne n’a mis en place l’application des périmètres côté serveur. Deux problèmes différents. Une solution non construite.
La spécification d’autorisation MCP est concrète. Elle définit des rôles distincts, des dépendances RFC spécifiques et des modèles non négociables pour la circulation des jetons. Comprendre ces modèles est ce qui distingue une configuration qui fonctionne d’une configuration qui semble fonctionner, jusqu’au jour où ce n’est plus le cas.
Ce que les équipes découvrent trop tard
- L’autorisation MCP est OAuth 2.1 appliqué aux contextes d’agents IA, et non un nouveau protocole inventé pour MCP.
- Le serveur d’autorisation et le serveur MCP ont des rôles séparés qui ne se chevauchent pas ; les confondre est le point de départ de la plupart des incidents en production.
- L’authentification confirme l’identité ; l’autorisation applique ce que cette identité peut faire. La spécification couvre les deux, mais par des mécanismes distincts qui doivent chacun être implémentés.
- L’intégration du SSO d’entreprise nécessite un travail d’architecture volontaire qui va largement au-delà de ce que fournit la spécification de base.
- « Facultatif au niveau du protocole » ne signifie pas facultatif en production.
Ce qu’est réellement l’autorisation MCP — et ce que couvre la spécification
L’autorisation MCP est le mécanisme par lequel des clients MCP basés sur HTTP obtiennent des jetons d’accès OAuth 2.1 auprès d’un serveur d’autorisation dédié et présentent ces jetons à des serveurs MCP faisant office de serveurs de ressources. Cette phrase comprend trois éléments mobiles, et chacun compte.
Le client MCP est le consommateur : un agent IA, un copilote d’IDE ou un workflow d’automatisation qui effectue des requêtes. Le serveur d’autorisation est un service distinct qui authentifie le client, recueille le consentement de l’utilisateur et émet des jetons. Le serveur MCP reçoit ces jetons à chaque requête et les valide avant d’autoriser l’exécution d’un outil. Dans le modèle OAuth 2.1, il s’agit du serveur de ressources.
Ce que couvre l’autorisation dans MCP : la spécification du Model Context Protocol définit précisément la manière dont s’effectue cet échange de jetons, les flux requis et la façon dont les clients découvrent initialement le serveur d’autorisation. Ce qu’elle ne couvre pas : ce qui se passe dans vos API back-end une fois le jeton validé. Cette lacune est importante, et j’y reviendrai.
L’élément que la plupart des lecteurs manquent est que la spécification classe l’autorisation comme facultative au niveau du protocole, mais cette désignation concerne une connectivité minimale viable entre un client MCP et un serveur MCP dans un contexte local de confiance. Pour tout serveur MCP basé sur HTTP exposé à des clients non fiables, les recommandations de la spécification ne sont en réalité pas facultatives. Ce caractère facultatif est une désignation au niveau du protocole, et non une décision relative à la sécurité en production. Les équipes qui lisent « facultatif » et ignorent l’implémentation découvrent plus tard cette distinction auprès de leur équipe de sécurité, dans des conditions moins favorables.
Pourquoi le modèle d’autorisation MCP s’appuie sur OAuth 2.1 plutôt que sur un nouveau protocole
Le choix délibéré de s’appuyer sur OAuth 2.1 plutôt que d’inventer un mécanisme personnalisé mérite d’être compris avant d’évaluer toute implémentation MCP. La spécification MCP n’avait pas besoin de résoudre l’identité et le consentement à partir de zéro. Ces problèmes disposent déjà de solutions, et ces solutions reposent déjà sur une infrastructure.
Il s’agit d’une décision architecturale aux implications pratiques réelles. Si votre équipe exploite déjà une infrastructure OAuth 2.1, vous partez d’une surface de sécurité connue. Votre équipe de sécurité sait quoi auditer. Votre IdP sait avec quoi s’intégrer. Vous n’introduisez pas une surface d’attaque entièrement nouvelle dans votre environnement de production. Il s’agit d’une réduction de risque réelle, et non d’un argument marketing.
L’analyse technique d’Aembit de la spécification d’autorisation MCP le documente explicitement : la spécification standardise l’accès des clients aux ressources protégées à l’aide d’OAuth 2.1 avec PKCE et introduit les métadonnées de ressources protégées afin de dissocier le contrôle des accès des serveurs MCP et de l’aligner sur l’infrastructure d’identité existante. L’implication pratique de cette dernière expression — « s’aligner sur l’infrastructure d’identité existante » — est que les équipes qui utilisent déjà l’autorisation OAuth peuvent connecter MCP à leur pile d’identité existante au lieu d’en créer une parallèle.
Le choix de tirer parti des modèles d’autorisation existants est important pour les architectes qui évaluent les risques dans un délai donné. Vous auditez l’implémentation, pas le protocole. Les bugs de votre implémentation d’autorisation MCP sont des bugs OAuth 2.1 : ils disposent de voies de remédiation connues, de CVE documentées et d’une communauté de sécurité qui les identifiera. Un protocole personnalisé n’offre aucune de ces garanties historiques.
L’autorisation OAuth dans le contexte MCP signifie également que le flux de code d’autorisation est le modèle principal, avec PKCE requis pour les clients publics. La raison pour laquelle cette combinaison spécifique est pertinente devient claire dans la section suivante.
Pourquoi OAuth 2.1 et PKCE conviennent parfaitement aux clients d’agents IA
PKCE (Proof Key for Code Exchange) répond à un problème précis : comment protéger un échange de code d’autorisation OAuth 2.1 lorsqu’un client ne peut pas stocker un secret de façon sûre ? Une application mobile native ne peut pas stocker un secret client de manière sécurisée. Une extension de navigateur non plus. Et un agent IA ou un copilote d’IDE exécuté comme client public ne le peut pas davantage.
C’est exactement le cas d’usage d’un hôte MCP. Lorsqu’un agent IA agit au nom d’un utilisateur, il fonctionne comme un client public. Stocker un secret client dans un processus d’agent exécuté dans des environnements contrôlés par les utilisateurs n’est pas une mesure de sécurité significative. L’interception d’un code d’autorisation constitue une véritable voie d’attaque pour ces clients si l’échange n’est pas protégé.
PKCE comble cette lacune. Le client génère un vérificateur de code avant la requête d’autorisation, envoie son hachage — le défi de code — avec la requête, puis prouve qu’il détient le vérificateur original lors de l’échange du code d’autorisation contre un jeton. Un code intercepté est inutilisable sans le vérificateur. Les clients MCP et les serveurs MCP opérant dans des contextes de client public bénéficient d’une protection réelle du code d’autorisation sans avoir besoin d’un secret qui ne peut, de toute façon, pas rester secret. C’est pourquoi la spécification l’exige : non comme une recommandation de bonne pratique, mais comme une exigence structurelle pour cette catégorie de client.
Les dépendances RFC que la plupart des équipes ignorent avant l’implémentation
La spécification d’autorisation MCP ne fonctionne pas seule. Elle dépend d’un ensemble de RFC que la plupart des équipes n’inventorient pas complètement avant de construire leur solution. Omettre l’une d’elles dans vos implémentations MCP produit une configuration partiellement conforme et totalement défaillante dans certains cas limites.
La liste de contrôle qui distingue les implémentations conformes des implémentations défaillantes, tirée des propres exigences de la spécification et de l’analyse terrain de Christian Posta :
- OAuth 2.1 avec PKCE — l’exigence fondamentale du flux pour les clients publics ; non facultative pour les déploiements basés sur HTTP.
- RFC 8414 — Métadonnées du serveur d’autorisation — permet aux clients de découvrir automatiquement les points de terminaison du serveur d’autorisation via une URL well-known ; sans cela, les clients nécessitent une configuration codée en dur.
- RFC 9728 — Métadonnées de ressources protégées pour l’autorisation — permet au serveur MCP d’annoncer l’emplacement de son serveur d’autorisation aux clients qui reçoivent une réponse 401 ; c’est ainsi que les clients savent où obtenir des jetons dès le départ.
- RFC 7591 — Enregistrement dynamique des clients — permet aux clients de s’enregistrer auprès du serveur d’autorisation par programmation ; particulièrement important pour les outils et agents qui ne peuvent pas être préenregistrés manuellement.
- RFC 8707 — Indicateurs de ressources — permet de limiter les jetons à des serveurs de ressources spécifiques, réduisant le risque qu’un jeton émis pour un serveur MCP soit rejoué contre un autre.
Les équipes qui implémentent OAuth 2.1 mais ignorent la RFC 9728 se retrouvent avec des clients incapables de découvrir le serveur d’autorisation sans configuration manuelle. Celles qui ignorent la RFC 7591 présentent une lacune d’enregistrement dynamique des clients qui devient importante dès qu’elles doivent intégrer des agents par programmation à grande échelle. Les métadonnées de découverte du serveur d’autorisation de la RFC 8414 sont ce qui rend l’ensemble de l’échange automatisable. Omettez-les et vous aurez construit quelque chose qui fonctionne dans votre environnement de test, mais échoue lorsqu’une personne essaie de connecter un nouveau type de client.
Comment fonctionne le flux d’autorisation MCP : rôles, jetons et limites de responsabilité
Le flux d’autorisation dans MCP suit une séquence spécifique, et l’attribution des rôles à chaque étape est l’élément qui déroute le plus les équipes. Parcourons-le avec des frontières explicites, car c’est là que se trouvent la plupart des erreurs d’implémentation.
Un client tente d’appeler un point de terminaison protégé d’un serveur MCP. Le serveur renvoie une réponse 401 avec des en-têtes WWW-Authenticate pointant vers ses métadonnées de ressources protégées. Le client récupère ces métadonnées afin de découvrir l’emplacement du serveur d’autorisation. Il lance ensuite le flux de code d’autorisation OAuth 2.1 avec PKCE auprès de ce serveur d’autorisation, en redirigeant l’utilisateur afin qu’il donne son consentement. Le serveur d’autorisation authentifie l’utilisateur, recueille son consentement et renvoie un code d’autorisation. Le client échange ce code, avec son vérificateur PKCE, contre un jeton d’accès. À chaque requête suivante adressée au serveur MCP, le client présente ce jeton dans l’en-tête Authorization. Le serveur MCP valide le jeton et applique les périmètres.
Il s’agit du flux d’autorisation de bout en bout. Deux actions ont lieu à deux endroits complètement différents. Le serveur d’autorisation gère l’identité et le consentement. Le serveur MCP gère l’application des règles. Ce sont des responsabilités et des implémentations distinctes. Les confondre est à l’origine de la plupart des incidents de sécurité en production que je vois décrits lorsque les équipes signalent des problèmes avec des déploiements MCP.
Ce que gère le serveur d’autorisation et ce qu’applique le serveur MCP
La répartition du travail est précise et non négociable. Un serveur d’autorisation gère l’authentification, la collecte du consentement et l’émission des jetons. Le travail du serveur MCP commence une fois le jeton créé.
Le serveur d’autorisation est responsable de vérifier l’identité du client, de confirmer que l’utilisateur a consenti aux périmètres demandés, d’émettre un jeton d’accès signé contenant ces périmètres et, le cas échéant, d’émettre des jetons de rafraîchissement pour les sessions longues. Il ne sait pas et n’a pas à se préoccuper de ce que le serveur MCP fera du jeton une fois reçu. Ce problème n’est pas celui que le serveur d’autorisation doit résoudre.
La responsabilité du serveur MCP commence à la réception du jeton. Les serveurs MCP doivent valider le jeton à chaque requête : vérifier la signature, contrôler l’émetteur, confirmer que la revendication d’audience correspond à ce serveur spécifique et appliquer les revendications de périmètre à l’outil invoqué. La logique d’autorisation au niveau du serveur MCP n’est pas un simple relais. C’est une étape active d’application des règles à chaque requête.
L’erreur fréquente est la suivante : les équipes construisent correctement l’intégration du serveur d’autorisation, puis supposent que le serveur MCP est « autorisé » parce qu’il a reçu un jeton valide. Un jeton cryptographiquement valide mais contenant les mauvais périmètres pour l’outil demandé doit être rejeté. Ce rejet intervient au niveau du serveur MCP. Un serveur d’autorisation peut servir plusieurs serveurs MCP, mais chaque serveur doit définir ses propres exigences de périmètre et les appliquer indépendamment. Vous ne pouvez pas définir plusieurs serveurs d’autorisation et considérer que l’application des périmètres relève de la responsabilité de quelqu’un d’autre. Ce n’est jamais le cas.
Cycle de vie des jetons d’accès et de rafraîchissement dans le contexte MCP
Les jetons d’accès dans MCP suivent le modèle OAuth 2.1 : ils sont de courte durée, limités à des périmètres et validés à chaque requête. Leur courte durée de vie n’est pas une simple recommandation. L’analyse de la spécification par Aembit indique précisément que les recommandations MCP interdisent explicitement les sessions côté serveur et imposent la validation des jetons à chaque requête. Cela rompt avec une pratique à laquelle les équipes issues de l’architecture d’applications web traditionnelles ont tendance à recourir instinctivement.
Dans une application web basée sur les sessions, vous vous authentifiez une fois et la session persiste. Un client MCP ne peut pas faire cette hypothèse. Chaque appel au serveur MCP valide le jeton d’accès auprès du serveur d’autorisation. La spécification n’autorise aucun raccourci du type « nous avons déjà vérifié cet utilisateur il y a cinq minutes ». Il s’agit d’un choix de conception délibéré visant à réduire le risque qu’une session compromise donne un accès illimité pendant une longue période.
Le jeton de rafraîchissement existe pour les sessions d’agents de plus longue durée. Lorsqu’un jeton OAuth expire au milieu d’un workflow — ce qui se produira dans toute session d’agent qui dépasse la durée de vie du jeton — le client utilise un jeton de rafraîchissement pour obtenir un nouveau jeton d’accès sans exiger que l’utilisateur redonne son consentement de manière interactive. L’autorisation initiale nécessite la présence et le consentement de l’utilisateur. Les rafraîchissements de jetons ultérieurs dans la même session ne l’exigent pas. C’est le modèle approprié pour les workflows d’agents IA susceptibles de s’exécuter sur des périodes prolongées.
Une remarque pratique de configuration : si vous exécutez des sessions d’agents pouvant durer des heures, la durée de vie du jeton d’accès doit être définie avec soin. Trop courte, et vous rafraîchirez constamment les jetons, ajoutant de la latence et des points de défaillance. Trop longue, et vous réduirez l’effet de limitation du rayon d’impact que la spécification est conçue pour apporter. Commencer avec une durée de vie de jeton d’accès de 15 à 30 minutes et un cycle de rafraîchissement selon les besoins constitue une configuration initiale raisonnable ; ajustez-la selon vos exigences spécifiques de durée de session, et non comme une règle fixe.
L’authentification et l’autorisation dans MCP ne sont pas le même problème
Je vois continuellement ces deux notions être confondues, ce qui produit un type précis d’incident en production particulièrement pénible à déboguer, car le système semble fonctionner correctement de l’extérieur.
L’authentification répond à la question : qui est ce client MCP ? Le serveur d’autorisation s’en charge. Il vérifie l’identité du client et de l’utilisateur final, confirme les identifiants et atteste cette identité dans le jeton qu’il émet. Lorsque l’authentification réussit, vous savez qui effectue la requête.
L’autorisation répond à la question : que cette identité est-elle autorisée à faire ? Le serveur MCP s’en charge. Il récupère l’identité authentifiée dans le jeton, lit les revendications de périmètre et décide si ce client précis, disposant de ces périmètres précis, est autorisé à invoquer cet outil MCP précis à ce moment donné. Les capacités d’autorisation sont appliquées au niveau du serveur, et non au niveau de l’émission du jeton.
Le mode de défaillance observé en pratique : une équipe implémente correctement l’authentification, vérifie que le client reçoit un jeton valide, puis n’implémente pas l’application des périmètres sur le serveur. L’authentification semble correcte. La connexion fonctionne. Chaque outil du serveur devient alors accessible à tout client authentifié, quels que soient les périmètres accordés. Ce n’est pas un cas limite. C’est la lacune d’autorisation MCP la plus courante que je vois décrite lorsque les équipes signalent des préoccupations de sécurité après le déploiement initial.
La spécification traite les deux via des mécanismes d’autorisation distincts qui doivent chacun être implémentés. Un client MCP qui reçoit un jeton a été authentifié. Ce que ce jeton lui permet de faire dépend entièrement de ce que le serveur MCP applique lorsqu’il valide les revendications de périmètre et d’audience du jeton. Un jeton valide n’est pas un chèque en blanc. Chaque invocation d’outil doit être accompagnée d’un contrôle de périmètre.
C’est généralement à ce moment-là que le ticket est créé.
🤔 Attendez.
La spécification MCP classe l’autorisation comme facultative au niveau du protocole. Mais tout serveur MCP distant basé sur HTTP, exposé à des clients non fiables et sans couche d’autorisation, accepte des requêtes de quiconque peut l’atteindre. « Facultatif » signifie ici que le protocole fonctionnera sans cette couche. Cela ne signifie pas que le déploiement est sécurisé sans elle. Interprétez la désignation de facultatif de la spécification comme un minimum de connectivité, et non comme une base de sécurité.
Là où la spécification d’autorisation MCP ne répond pas aux besoins des environnements d’entreprise
La spécification d’autorisation MCP de base fait ce qu’elle annonce. Le problème est que ce qu’elle annonce ne correspond pas à ce dont les équipes de sécurité d’entreprise ont besoin. Il ne s’agit pas d’une critique de fournisseur. C’est un écart architectural entre ce que définit la spécification MCP et ce que requièrent réellement les environnements IAM des grandes organisations.
Le modèle actuel d’autorisation MCP est conçu autour d’OAuth 2.1 comme mécanisme autonome. Il gère proprement le flux de jetons entre le client et le serveur. En revanche, il ne définit pas comment ce flux s’intègre à l’infrastructure d’identité d’entreprise existante : Microsoft Entra, Okta, les IdP internes basés sur LDAP, la fédération SAML ou tout autre système d’identité autour duquel les équipes de sécurité d’entreprise ont passé des années à construire des politiques.
Les versions de la spécification d’autorisation MCP disponibles aujourd’hui supposent soit que vous exploitez un serveur d’autorisation autonome, soit que vous résoudrez vous-même l’intégration avec votre IdP. Pour une startup de 15 personnes qui déploie son premier serveur MCP, cela convient. Pour une organisation où chaque événement d’authentification doit transiter par un fournisseur d’identité centralisé, respecter les politiques SSO et générer des événements d’audit dans un SIEM, la spécification de base fournit la couche de transport et laisse la couche de politiques de niveau entreprise comme exercice au lecteur.
La communauté MCP discute activement de cette lacune. Les recommandations de cybersécurité de la NSA sur MCP avertissent explicitement que MCP ne prend actuellement pas en charge l’échange des autorisations de contrôle d’accès basé sur les rôles lors de l’instanciation, ce qui complique l’application ou la vérification des limites d’accès entre les tâches dans les déploiements complexes. Il s’agit d’une lacune significative si votre posture de sécurité MCP dépend d’un RBAC résolu à l’exécution plutôt qu’à l’émission des jetons.
Les équipes prévoyant de déployer des serveurs MCP à l’échelle de l’entreprise doivent considérer la spécification comme une fondation et planifier un travail architectural supplémentaire au-dessus, et non comme une solution complète. Une implémentation conforme à la spécification ne signifie pas automatiquement un déploiement prêt pour l’entreprise.
Intégrer les fournisseurs d’identité existants au modèle d’autorisation MCP
Pour les équipes IAM d’entreprise, la lacune précise se situe entre ce que définit la spécification — un rôle abstrait de serveur d’autorisation — et ce qu’elles exploitent réellement : un IdP concret tel qu’Entra ID ou Okta, avec des relations de fédération, des appartenances à des groupes et des points d’application des politiques déjà en place.
La spécification autorise tout service compatible avec OAuth 2.1 à agir comme serveur d’autorisation. En théorie, Entra ID ou Okta peuvent jouer ce rôle. En pratique, faire en sorte que les clients MCP découvrent et utilisent correctement les IdP d’entreprise exige un travail de configuration sur lequel la spécification ne fournit pas de directives, notamment concernant la correspondance entre les métadonnées de ressources protégées et les points de terminaison d’autorisation propres à l’IdP, ainsi que l’alignement des périmètres avec les structures de rôles de l’entreprise.
Le risque d’implémenter MCP avec un serveur d’autorisation autonome plutôt que de l’intégrer à l’IdP existant est de créer un deuxième silo d’identité. L’accès aux outils MCP devient alors régi par des politiques qui existent en dehors du système IAM d’entreprise, sont gérées séparément, auditées séparément et ne sont pas intégrées aux processus centraux de gouvernance des identités.
L’autorisation externe via des services d’autorisation tiers, ou une intégration étroite entre la couche d’autorisation MCP et les IdP internes existants, constitue la direction recommandée pour les environnements d’entreprise. Une gestion des autorisations rattachée à un serveur d’autorisation MCP autonome, auquel personne dans l’équipe de sécurité n’a de visibilité, correspond exactement au type de magasin d’identifiants parallèle que les équipes de sécurité d’entreprise tentent d’éliminer. Implémenter MCP correctement à l’échelle de l’entreprise implique de résoudre délibérément ce problème d’intégration IdP, et non d’espérer qu’il se résolve de lui-même.
Pourquoi sécuriser MCP pour les identités d’agents non humains est plus difficile
Le flux de code d’autorisation OAuth 2.1 suppose la présence d’un humain pour s’authentifier et donner son consentement. Les agents IA et les pipelines automatisés ne disposent pas de cette possibilité. Un agent qui doit appeler un serveur MCP à 3 heures du matin au milieu d’un workflow ne peut pas rediriger un navigateur et attendre que quelqu’un clique sur « Autoriser ».
C’est la lacune que laisse ouverte la spécification. L’analyse de la spécification d’Aembit identifie l’authentification forte des agents et l’identité attestée par l’infrastructure comme le modèle nécessaire pour la combler. L’idée est la suivante : au lieu d’exiger un consentement interactif pour les agents non humains, l’infrastructure atteste l’identité selon des attributs vérifiables de la charge de travail elle-même. L’identité de l’agent provient de son environnement d’exécution, et non d’identifiants qu’il détient et qui pourraient potentiellement fuiter.
Un serveur MCP peut utiliser des modèles d’autorisation spécifiques pour les flux machine à machine, notamment le flux d’identifiants client OAuth 2.1 dans les contextes non interactifs. Mais cela exige une gestion réfléchie des identifiants : dans cette configuration, les serveurs MCP agissent comme des clients OAuth, et les identifiants émis pour l’accès machine à machine nécessitent des politiques de rotation, des contraintes de périmètre et des procédures de révocation que la spécification ne prescrit pas. La complexité de l’authentification des identités non humaines ne disparaît pas avec le choix du protocole. Elle se déplace simplement ailleurs. Sécuriser MCP pour des pipelines automatisés qui ne peuvent pas obtenir un consentement interactif est le problème d’implémentation que les équipes ayant résolu la spécification de base doivent résoudre à nouveau à partir de zéro lorsqu’elles introduisent des workflows agentiques.
Bonnes pratiques d’autorisation MCP qui évitent réellement les défaillances courantes
Chaque point ci-dessous identifie un mode de défaillance spécifique ainsi que le contrôle ou la décision de conception qui l’empêche. Il ne s’agit pas de recommandations de sécurité génériques. Elles reposent sur ce que la spécification exige et sur ce qui échoue lorsque les équipes omettent des étapes.
Appliquez la validation des jetons à chaque requête, sans jamais réutiliser une confiance de session
La spécification l’impose. Le mode de défaillance concerne une équipe habituée aux applications web basées sur les sessions, qui met en cache le fait que « ce client a été autorisé il y a cinq minutes » et ignore la revalidation. Lorsque le jeton est révoqué ou expire, le serveur MCP continue d’accepter les requêtes jusqu’à l’expiration du cache. Validez le jeton à chaque appel au serveur MCP, et non une seule fois au démarrage de la session.
Implémentez l’application des périmètres au niveau de l’outil, pas uniquement au moment de la connexion
Un jeton dont l’authentification est valide mais qui ne possède pas les périmètres propres à l’outil doit être rejeté au point d’invocation de l’outil. L’erreur fréquente consiste à vérifier que le jeton est valide, confirmer que le client est connecté, puis autoriser n’importe quel appel d’outil. Les serveurs MCP doivent vérifier les périmètres par rapport à l’outil précis invoqué à chaque requête. Un jeton limité à la lecture ne doit pas pouvoir appeler un outil d’écriture, même si la connexion a réussi.
Prenez en charge l’enregistrement dynamique des clients via la RFC 7591
Les clients MCP doivent prendre en charge l’enregistrement programmatique au lieu d’exiger que tous les clients soient préenregistrés manuellement. Sans cela, le mode de défaillance est simple : vous ne pouvez pas intégrer de nouveaux clients agents à grande échelle sans une étape de configuration manuelle pour chacun. Autorisez les clients MCP à s’enregistrer dynamiquement et assurez-vous que les clients enregistrés dynamiquement reçoivent des périmètres correctement contraints plutôt qu’un accès global.
Exigez PKCE pour tous les flux de code d’autorisation, sans exception
Ignorez PKCE pour un flux qui semble « sûr » aujourd’hui et vous laissez ouverte une voie d’interception de code d’autorisation. La spécification exige PKCE pour les clients publics. Traitez-le comme une exigence universelle plutôt que comme une décision au cas par cas. Tout nouveau flux d’autorisation ajouté à votre implémentation doit inclure PKCE par défaut.
Transmettez les jetons dans l’en-tête Authorization, et non dans le corps de la requête ou la chaîne de requête
C’est un principe d’hygiène basique du transport qui est plus souvent négligé qu’il ne devrait l’être. Un jeton d’accès dans une chaîne de requête apparaît dans les journaux serveur, l’historique du navigateur et les en-têtes de référent. Dans l’en-tête, ce n’est pas le cas. Chaque implémentation de l’envoi de jetons des clients vers le serveur MCP doit vérifier que l’en-tête est bien le mécanisme de transmission.
L’autorisation MCP ne remplace pas les contrôles d’accès des API en aval
C’est l’idée fausse la plus coûteuse que je constate dans la manière dont les équipes évaluent leur posture de sécurité après avoir implémenté l’autorisation MCP. L’autorisation MCP contrôle l’accès au serveur MCP et à ses outils. Les services sous-jacents appelés par ces outils — vos API internes, bases de données et systèmes SaaS — doivent toujours disposer de leurs propres contrôles d’accès. Un jeton qui autorise l’invocation d’un outil au niveau MCP n’autorise pas tout ce que cet outil pourrait faire en aval. La couche centrale d’autorisation MCP et l’autorisation des services en aval sont des points d’application indépendants qui doivent chacun être implémentés. Les équipes qui implémentent la couche MCP et se déclarent sécurisées auront une surprise désagréable.
Utilisez des jetons de rafraîchissement avec rotation pour les sessions d’agents longues
L’expiration d’un jeton d’accès pendant un workflow d’agent à plusieurs étapes est une défaillance de fiabilité que les équipes rencontrent rapidement. L’architecture correcte consiste à émettre un jeton de rafraîchissement lors de l’autorisation initiale et à l’utiliser pour obtenir de nouveaux jetons d’accès sans interrompre le workflow. Utilisez la rotation des jetons afin que chaque rafraîchissement invalide le jeton de rafraîchissement précédent, ce qui limite le rayon d’impact d’un jeton de rafraîchissement volé.
📊 En pratique :
La validation des jetons à chaque requête auprès du serveur d’autorisation est imposée par la spécification — et elle rompt directement avec le modèle courant de confiance fondée sur les sessions que les équipes importent de l’authentification web traditionnelle. Le contrôle d’implémentation est concret : si votre serveur MCP comporte un chemin de code où un jeton client déjà vu contourne la validation parce que « nous l’avons déjà vérifié », ce chemin de code enfreint simultanément la spécification et votre posture de sécurité. Supprimez-le.
Qui utilise l’autorisation MCP et ce qu’ils cherchent réellement à contrôler
En pratique, trois types d’équipes rencontrent des problèmes d’autorisation MCP, et chacune tente de contrôler quelque chose de différent.
Les équipes de plateformes IA qui créent des outils à appeler par des agents cherchent principalement à contrôler quels clients MCP peuvent accéder à quels outils via les périmètres et les rôles. Le premier serveur MCP qu’elles déploient commence généralement sans contrôles de périmètre au-delà de « authentifié ou non ». Le problème apparaît lorsqu’elles doivent autoriser un agent d’analytique en lecture seule à consulter les résultats des outils tout en l’empêchant d’appeler des opérations d’écriture. Le flux de code d’autorisation avec une conception adéquate des périmètres résout ce problème, mais il impose de réfléchir à la taxonomie des périmètres avant de construire le serveur, et non après. La spécification MCP fournit le mécanisme. Vous devez définir les périmètres qui méritent d’être appliqués.
Les équipes de sécurité et IAM cherchent à centraliser les politiques afin de ne pas gérer un magasin d’identifiants distinct pour chaque déploiement MCP. Leur objectif est l’intégration OAuth 2.1 avec l’IdP : chaque jeton MCP doit pouvoir être retracé jusqu’à un événement d’identité dans le fournisseur d’identité central, et non dans un serveur d’autorisation autonome. Elles veulent des jetons de courte durée, des revendications d’audience de serveur de ressources claires dans chaque jeton et la capacité de révoquer l’accès en révoquant la session de l’IdP. Les identifiants larges et de longue durée qui ne sont pas intégrés à la gouvernance IAM centralisée sont précisément ce qu’elles cherchent à éliminer. L’autorisation MCP leur fournit le modèle. Le faire fédérer avec leur IdP existant constitue le travail d’implémentation.
Les fournisseurs SaaS et d’infrastructure qui exposent des serveurs MCP à des clients externes ont besoin d’une intégration SSO d’entreprise et d’une configuration automatisée des clients via les métadonnées d’emplacement du serveur d’autorisation. Les agents de leurs clients doivent découvrir le serveur d’autorisation, s’enregistrer dynamiquement et obtenir des jetons aux périmètres appropriés, le tout sans étape d’intégration manuelle pour chaque client. Les RFC 8414 et RFC 9728 ne sont pas des dépendances théoriques dans ce cas d’usage. Elles constituent le mécanisme qui rend possible l’intégration programmatique. Sans elles, chaque nouveau client exige une configuration manuelle.
Pour les équipes qui construisent des workflows d’automatisation sur des serveurs autorisés par MCP, le même modèle de jetons et de périmètres s’applique au sein de l’implémentation. Un workflow qui écoute les réponses 401 des serveurs MCP, pilote de façon centralisée l’échange OAuth 2.1 + PKCE et effectue les appels avec le jeton obtenu constitue un modèle plus propre que l’intégration de la gestion de l’authentification dans chaque intégration individuelle. Latenode prend cela en charge grâce à des nœuds JavaScript capables de gérer la logique d’échange de jetons et à ses plus de 5 500 intégrations avec OAuth automatique pour les connexions aux services sous-jacents — le type de configuration qui transforme un projet d’authentification de plusieurs semaines en un déploiement réalisable en un après-midi, une fois le flux modélisé.
