MCP et OAuth2 : Qui a autorisé l’action de l’agent sur votre serveur MCP ?

Pourquoi l’accès aux outils complique l’identification

Le Model Context Protocol (MCP) est désormais un élément standard pour les IA agentes. Il permet à un modèle de découvrir et d’appeler des outils, des ressources et des services externes. Il n’est pas nécessaire de mettre en place une intégration personnalisée entre un LLM et chaque API qu’il utilise ; l’application se connecte à un serveur MCP pour découvrir ce que ce serveur propose. La recherche dans une base de données, la soumission d’un problème sur GitHub, la consultation de Salesforce, l’envoi d’un e-mail ou la récupération de données dans un système d’entreprise se réduisent toutes à la même opération : une appel à un outil.

Dès qu’une intelligence artificielle peut agir et non pas seulement répondre, l’identité et l’autorisation deviennent rapidement complexes. Qui est l’intelligence artificielle, et qui est l’être humain derrière elle ? Qui a autorisé l’action, et que peut exactement faire l’intelligence artificielle ? À quelles ressources cette autorisation s’applique-t-elle ? L’intelligence artificielle peut-elle transférer cette autorité à un autre service ? Et la question la plus importante : OAuth2, un protocole conçu principalement pour permettre aux logiciels d’accéder à des ressources protégées, peut-il représenter de manière adéquate un agent autonome agissant au nom d’une personne ?

La réponse est complexe. L’expression « au nom de » renvoie au protocole d’échange de tokens OAuth2. La spécification actuelle de MCP ne le mentionne pas, bien qu’il soit facile de voir où il pourrait s’intégrer, et cela ne résoudrait pas les autres défauts évoqués ci-dessus.

Comment MCP fonctionne en pratique

MCP définit un protocole standard entre un client d’intelligence artificielle et un serveur MCP. Une représentation simplifiée en est la suivante.

L’application d’IA est le client MCP, et le serveur MCP lui expose des capacités. Le modèle peut découvrir ces capacités et décider quand les utiliser. Le changement notable est que le LLM ne se contente plus de produire du texte : il participe à un protocole.

Imaginez un assistant connecté à un serveur MCP pour un suivi des problèmes au sein d’une entreprise. D’abord, le client demande au serveur quels outils il dispose.

{
  "method": "tools/list",
  "params": {}
}

Le serveur répond avec sa liste d’outils.

{
  "tools": [
    {
      "name": "search_issues",
      "description": "Search project issues",
      "inputSchema": {
        "type": "object",
        "properties": {
          "query": {
            "type": "string"
          }
        }
      }
    },
    {
      "name": "create_issue",
      "description": "Create a new project issue",
      "inputSchema": {
        "type": "object",
        "properties": {
          "title": {
            "type": "string"
          },
          "description": {
            "type": "string"
          }
        }
      }
    }
  ]
}

Désormais, le modèle sait qu’il dispose de deux capacités. Supposons que l’utilisateur lui demande de trouver les bugs d’authentification non corrigés et de créer un rapport résumant le plus important d’entre eux. L’agent pourrait commencer par effectuer une recherche.

{
  "method": "tools/call",
  "params": {
    "name": "search_issues",
    "arguments": {
      "query": "authentication bugs status:open"
    }
  }
}

Le serveur renvoie des problèmes de correspondance.

{
  "content": [
    {
      "type": "text",
      "text": "Found 17 open authentication issues."
    }
  ]
}

Le modèle lit les résultats, sélectionne celui qui est le plus important et envoie une deuxième demande.

{
  "method": "tools/call",
  "params": {
    "name": "create_issue",
    "arguments": {
      "title": "Critical authentication issue",
      "description": "Summary of the highest-priority authentication defect..."
    }
  }
}

Le serveur confirme la création.

{
  "content": [
    {
      "type": "text",
      "text": "Issue AUTH-4821 created successfully."
    }
  ]
}

Ici, le problème de sécurité devient évident. L’agent est passé de la lecture d’informations à l’exécution d’une action visible en dehors du système.

MCP ne résout pas la question de l’identité

Une idée reçue courante est que MCP règle la question de l’identité. Ce n’est pas le cas. MCP définit la manière dont les clients et les serveurs interagissent, tandis que l’authentification et l’autorisation relèvent d’une problématique distincte.

Pour les transports basés sur HTTP, la section consacrée à l’autorisation dans la spécification actuelle (la révision du 2026-07-28) s’appuie sur OAuth 2.1. Cette section porte le titre d’« authorization », probablement parce que c’est le point central d’OAuth2, bien qu’elle couvre également des mécanismes d’authentification. Les serveurs MCP agissent comme des ressources protégées par OAuth2 et les clients MCP agissent comme des clients OAuth2. La spécification intègre également des éléments tels que les métadonnées des ressources protégées, les métadonnées des serveurs d’autorisation, les indicateurs de ressources, ainsi que le registre et la découverte des clients. Elle regroupe ainsi ces différentes spécifications :

• le projet IETF OAuth 2.1 (draft-ietf-oauth-v2-1-13)
• Utilisation des jetons porteurs OAuth 2.0 (RFC 6750)
• Métadonnées du serveur d’autorisation OAuth 2.0 (RFC 8414)
• Enregistrement dynamique des clients OAuth 2.0 (RFC 7591)
• Indicateurs de ressources pour OAuth 2.0 (RFC 8707)
• Métadonnées des ressources protégées OAuth 2.0 (RFC 9728)
• Identification de l’émetteur du serveur d’autorisation (RFC 9207)
• Documents de métadonnées pour l’ID du client OAuth (un projet IETF)
• OpenID Connect Discovery 1.0 et OpenID Connect Dynamic Client Registration 1.0

Le protocole se renforce de plus en plus. Lors de la révision de juillet 2026, les clients doivent vérifier le paramètre iss afin de bloquer les attaques de confusion avec les serveurs d’autorisation ; les identifiants des clients sont liés à l’émetteur qui les a créés, et l’inscription dynamique des clients est progressivement remplacée par des documents de métadonnées d’ID de client. La question de savoir si OAuth2 suffit pour les agents reste ouverte.

OAuth existe avant les agents

OAuth 2.0 a été standardisé en 2012 pour répondre à une question assez simple : comment un client peut-il obtenir un accès limité à une ressource protégée sans connaître le mot de passe du propriétaire de cette ressource ?

Le modèle a fonctionné très bien et est devenu la base de l’accès API délégué sur Internet. Cependant, l’IA autonome introduit un type de client différent. Auparavant, un client OAuth2 désignait une application. Un agent, lui, peut être autonome, fonctionner sur de longues périodes et effectuer plusieurs étapes, être capable de choisir des outils dynamiquement, d’appeler plusieurs APIs, de déléguer des tâches, d’agir au nom d’un humain et de prendre des décisions que celui-ci n’a jamais explicitement définies. Il s’agit là d’un problème d’autorisation complètement différent.

Ce n’est pas que OAuth soit peu sécurisé

Nul ne devrait exagérer les critiques. Le RFC 6749 prenait effectivement en compte des considérations de sécurité, et OAuth2 a depuis développé une architecture de sécurité considérable. L’idée est que OAuth2 a été délibérément conçu comme un cadre, et non comme un protocole prescriptif complet pour tous les déploiements modernes. Les implementateurs pouvaient faire de nombreuses choix en matière de sécurité, et avec le temps l’industrie a découvert que certaines combinaisons de ces choix étaient dangereuses. C’est la raison des ajouts qui ont suivi : l’authentification et la découverte des clients, les métadonnées des ressources protégées ainsi que les indicateurs de ressources, le TLS mutuel, DPoP et d’autres tokens restreints au niveau de l’expéditeur, le liage des tokens, PKCE et des directives relatives au renouvellement. Cette accumulation étant suffisamment importante, l’IETF a publié le RFC 9700, un document de meilleures pratiques actuelles pour la sécurité d’OAuth 2.0, qui s’appuie sur les RFC 6749, 6750 et 6819 et met à l’obsolescence les modes de fonctionnement moins sécurisés.

Donc OAuth2 n’a pas échoué. Il a évolué. Pourtant, cette évolution est elle-même un signe du problème sous-jacent : l’abstraction initiale a constamment nécessité des mécanismes supplémentaires à mesure que les environnements de sécurité devenaient plus complexes.

Que représente le jeton ?

Revenons à l’exemple précédent. L’utilisateur demande la création d’un élément, l’IA décide d’appeler un outil MCP, et le serveur reçoit un jeton d’accès OAuth2. Que représente ce jeton ? Il peut désigner l’utilisateur humain, l’application IA, le client MCP, le serveur MCP agissant au nom de l’utilisateur, ou une combinaison de l’application et de l’utilisateur. Ceux-ci ne sont pas équivalents, et selon des flux OAuth2 légèrement différents mais tout à fait légitimes, n’importe lequel d’entre eux peut se produire.

Cela devient encore plus important lorsque le serveur MCP appelle une autre API.

Divers domaines d’autorisation se chevauchent désormais. Avant d’agir, le serveur peut devoir déterminer l’identité de l’utilisateur, l’agent qui effectue la tâche, le client MCP qui a initié la demande, ce que l’utilisateur a approuvé, les outils que l’agent peut utiliser, les API intermédiaires accessibles, ainsi que savoir si cette action reste dans le cadre de l’autorisation initiale. Cela représente bien plus que la simple représentation ci-dessous.

Le délégué perplexe

Parmi les risques de sécurité les plus graves pour MCP figure le délégué confus. Supposons que le serveur MCP reçoive un jeton destiné à lui-même puis appelle une API en aval. Une implémentation négligente pourrait simplement transmettre ce jeton, et c’est précisément ce comportement que les directives de sécurité actuelles de MCP visent à empêcher. Selon la spécification, un serveur doit vérifier que le jeton lui a bien été émis et ne doit en aucun cas transmettre le jeton du client à un autre service. Lorsqu’il a besoin d’une API en amont, il doit obtenir un jeton différent émis pour cette ressource en aval. Le principe est le suivant :

et non celui-ci :

Le premier modèle crée des limites de confiance distinctes. L’ajout d’un gateway MCP complique encore les choses, mais la règle reste la même : ne jamais transmettre de jetons en aval.

Le rôle d’OAuth2 dans MCP

À un niveau simplifié, le flux se présente comme ceci.

Le serveur MCP est la ressource protégée. Le client obtient un jeton d’accès, le présente à chaque opération MCP, et le serveur le valide. C’est la méthode OAuth2 conventionnelle. La spécification la renforce grâce aux indicateurs de ressource (le paramètre resource), de sorte que la demande d’autorisation indique le serveur MCP spécifique auquel le jeton est destiné. C’est une bonne chose, mais cela ne résout pas magiquement tous les problèmes d’autorisation liés aux agents.

Ce que rajoute OIDC

OAuth2 indique ce à quoi un client a autorisation d’accéder. OIDC ajoute une couche d’identité qui précise qui est l’entité authentifiée, ce qui est utile pour les agents. Un fournisseur d’identité peut authentifier un utilisateur par exemple :

Alice

OIDC peut fournir des informations d’identité concernant cet utilisateur, OAuth2 peut assurer une autorisation déléguée, et le client MCP peut alors obtenir un jeton d’accès représentant une autorisation accordée au client pour un ressource spécifique. Conceptuellement, c’est ainsi que cela fonctionne.

Cependant, un manque conceptuel persiste : authentifier l’utilisateur ne signifie pas autoriser chacune des décisions prises par l’agent. Un utilisateur peut permettre à une application de lire ses e-mails, ce qui n’est pas identique à autoriser un agent IA à envoyer n’importe quel e-mail de son propre chef. C’est un problème de politique.

Les problèmes liés aux scopes

Les scopes sont souvent présentés comme la solution. Une autorisation de type « calendar-read » se présente de cette manière.

scope=calendar.read

et une subvention d’envoi comme celle-ci.

scope=email.send

Mais les systèmes agents révèlent à quel point les scopes sont grossiers. Prenons par exemple l’autorisation simple d’envoyer des e-mails.

email.send

Permet-il à l’IA d’envoyer des e-mails à qui que ce soit ? D’envoyer des messages illimités ? D’envoyer des documents financiers ou des données confidentielles de l’entreprise ? De se faire passer pour l’utilisateur ? D’envoyer des messages sans demander de confirmation ? La description ne le précise pas. La décision réelle pourrait nécessiter plus de contexte, dans ce sens-là.

Subject
Agent
Tool
Action
Resource
Target
Context
Risk
Time
Policy

Cela ressemble moins à des scopes OAuth2 traditionnels et plus à une autorisation basée sur des politiques. En termes plus anciens, c’est la différence entre des décisions d’autorisation à grande et à petite échelle.

L’agent en tant que nouveau sujet de sécurité

Ce pourrait être le changement conceptuel le plus important. Les applications traditionnelles possèdent généralement une identité assez stable. Un agent IA peut être assemblé dynamiquement, à partir de plusieurs composants en même temps.

Alors, qui est le sujet de sécurité ? Probablement tous ces éléments. Le système d’autorisation peut avoir besoin d’exprimer plus que simplement « Alice peut accéder à Salesforce ». Il peut être nécessaire d’indiquer qu’Alice a autorisé cet agent en particulier, fonctionnant via cette application spécifique, à effectuer certaines actions sur ce tenant Salesforce, sous réserve de certaines politiques. C’est une affirmation bien plus riche.

C’est aussi similaire à tout système qui met en cache de nombreux tokens d’accès provenant d’un grand pool d’utilisateurs, humains et applications, afin d’accéder à de nombreuses ressources intermédiaires. La question est de savoir si l’agent peut être considéré comme fiable pour protéger ces tokens et en choisir le bon au moment de prendre des actions au nom d’un utilisateur donné.

OAuth2 est-il défaillant pour les agents ?

Cette conclusion n’est pas justifiée. Une formulation plus appropriée serait que OAuth2 résout une partie du problème d’autorisation des agents, tandis que le problème global est plus complexe que ce que permet OAuth2. Il est très efficace pour l’accès délégué, qu’il met en place de cette manière.

Un écosystème d’agents a besoin de réponses plus approfondies : quel agent agit au nom de quelle personne, avec quel outil, à quelles fins, sur quelle ressource, sous quelle autorité et quelle politique, pendant combien de temps, dans quelles limites transactionnelles et avec quelle approbation humaine. Disposer d’un token d’accès ne résout aucune de ces questions.

Nouvelles propositions

Plusieurs orientations émergent.

GNAP

Le candidat basé sur des normes le plus évident est GNAP, le Grant Negotiation and Authorization Protocol. Il a été conçu pour surmonter les limites des mécanismes d’autorisation et de délégation de type OAuth2, en permettant de déléguer l’autorisation à du logiciel et de lui transmettre les éléments générés, couvrant à la fois l’accès aux API et les informations relatives aux utilisateurs. Sa conception prévoit une délégation plus poussée que celle offerte par OAuth2. GNAP est aujourd’hui une norme proposée par l’IETF sous la référence RFC 9635, et le RFC 9767 traite des connexions entre serveurs de ressources. Il répond bien à la question de savoir si quelqu’un a proposé quelque chose au-delà d’OAuth2, mais il ne constitue pas de remplacement spécifique à MCP, et OAuth2 reste dominant.

Protocoles de sécurité spécifiques à MCP

Les chercheurs proposent également des protocoles basés sur MCP et l’IA agente. Le Secure Model Context Protocol (SMCP) étendrait MCP grâce à une gestion unifiée des identités, une authentification mutuelle, une propagation du contexte de sécurité, une application fine des politiques et un enregistrement des audits. Une autre proposition, MCPSec, préconise l’attestation des capacités et l’authentification des messages afin de contrer les menaces spécifiques à MCP. Ces efforts reconnaissent que l’authentification n’est pas le seul problème : un écosystème d’agents devra déterminer non seulement qui vous êtes, mais aussi quelles capacités vous prétendez posséder et si ces affirmations peuvent être vérifiées de manière cryptographique. Cela mène vers une sécurité basée sur les capacités.

Authorization basée sur les capacités

Cela pourrait s’avérer plus important que de remplacer OAuth. Au lieu de donner à un agent la portée email.send, le système pourrait lui confier une capacité définie de manière très précise.

Capability:
    Principal: Agent-472
    Subject: Alice
    Action: send-email
    Resource: alice@example.com
    Destination: bob@example.com
    Maximum: 1 message
    Expiration: 10 minutes

L’agent possède un artefact d’autorisation vérifiable cryptographiquement et ne peut pas réutiliser cette autorité pour quoi que ce soit d’autre. Cela correspond beaucoup mieux à ce dont ont besoin les systèmes d’agents, car l’agent n’est pas seulement authentifié : il a reçu une autorité spécifique.

OAuth2 associé à d’autres éléments

L’architecture finale ne déclarera probablement pas OAuth2 obsolète. Elle ressemblera plutôt à ceci.

OAuth2 continue d’émettre des tokens d’accès, OIDC permet d’identifier les personnes, MCP fournit le protocole d’outils, un système de capacités ou de politiques limite ce que l’agent peut réellement faire, et un point d’application des politiques effectue la décision finale.

Le élément manquant : l’intention

L’intention est quelque chose que l’autorisation traditionnelle n’a pas été conçue pour gérer. Supposons qu’un utilisateur demande à un agent de trouver un vol pour Manille à moins de 1 000 dollars et de le réserver. Au cours de cette démarche, l’agent peut rechercher des compagnies aériennes, comparer les tarifs, consulter le calendrier, afficher les détails du passeport, réserver un siège et effectuer le paiement. L’utilisateur n’a jamais approuvé chacune de ces demandes API individuellement ; il a plutôt approuvé une intention, ce qui diffère fortement de l’autorisation web conventionnelle, car l’agent transforme une instruction générale en une série d’actions automatisées. Le système de sécurité peut devoir raisonner à ce sujet.

C’est pourquoi l’affirmation selon laquelle OAuth2 ne fonctionne pas pour les agents contient une part de vérité, à condition que cette critique soit interprétée correctement. OAuth2 peut autoriser chaque appel, mais il ne fournit pas intrinsèquement un moyen complet pour déterminer si ces appels correspondent à l’intention de la personne et aux pouvoirs délégués à l’agent.

MCP en tant que cas d’épreuve

MCP force la communauté de l’identité et de la sécurité à faire face à un problème qui se développe depuis des années. OAuth2 a été conçu autour de cette chaîne.

L’IA agente introduit quelque chose de différent.

La chaîne devient dynamique : les participants peuvent changer, l’agent prend des décisions, des outils sont découverts en temps réel, et le service final n’a peut-être jamais entendu parler de l’utilisateur initial. Pourtant, le système doit toujours répondre à la question de savoir qui a autorisé l’action, ce qui est une question bien plus difficile.

OAuth2 ne disparaîtra pas

Il est tentant de dire que OAuth2 existe avant l’IA et qu’il ne peut donc pas fonctionner avec elle. C’est trop simpliste. OAuth2 a survécu à d’énormes changements sur Internet car c’est un cadre de délégation véritablement utile, et la spécification MCP s’appuie explicitement sur OAuth 2.1 sans l’abandonner. L’avenir le plus probable est évolutif :

• OAuth2 en tant que fondement
• OIDC pour l’identité
• MCP pour une interaction standard avec les outils
• DPoP et mécanismes associés pour un lien plus fort entre les tokens
• Indicateurs de ressources pour relier les tokens aux ressources visées
• Systèmes de capacités pour limiter ce que les agents peuvent faire
• Moteurs de politiques pour évaluer le contexte
• Protocoles plus récents tels que GNAP pour des sémantiques de délégation plus riches

Le changement d’approche

L’IA agente ne crée pas principalement un nouveau problème d’authentification. Le nouveau problème concerne l’autorisation et la délégation. L’authentification demande qui vous êtes, tandis qu’OAuth2 demande à quels éléments vous avez accès. L’autorisation dans le cadre des agents doit déterminer quelle autorité a été déléguée à cet agent, au nom de qui, sur quelles ressources et sous quelles contraintes, et si cette action particulière en fait partie. C’est une question plus complexe, qui exige probablement un modèle de sécurité plus riche.

Le futur ne se jouera probablement pas entre OAuth2 et une technologie nouvelle. Il est plus probable que ce soit l’association d’OAuth2, d’OIDC, de MCP, de capacités, de politiques, de liens cryptographiques plus solides et d’une délégation consciente de l’agent. MCP fait simplement en sorte que les limites de l’architecture d’identité existante deviennent impossibles à ignorer, ce qui pourrait constituer l’une de ses contributions les plus importantes à l’écosystème de l’IA.