August 11, 2026

Authentification des agents d’IA via MCP

L’authentification et la propagation de l’identité dans les architectures d’agents IA via MCP est un enjeu central. Comment garantir qu’une…

By Charles Vissol

7 min read

L'authentification et la propagation de l'identité dans les architectures d'agents IA via MCP est un enjeu central. Comment garantir qu'une action effectuée par un agent — qui consomme des outils via le Model Context Protocol (MCP) — est bien autorisée par un humain identifié, et comment cette identité se propage-t-elle de manière sûre à travers une chaîne d'appels API ? La réponse repose sur une combinaison de plusieurs standards : OAuth 2.1, RFC 8693 (Token Exchange), RFC 9728 (Protected Resource Metadata), et des règles explicites de la spécification MCP qui interdisent certaines pratiques dangereuses comme le token passthrough.

Le problème fondamental : la confusion des frontières de confiance

Dans une architecture classique, un utilisateur s'authentifie auprès d'une application, qui appelle une API. L'identité de l'utilisateur est portée par un jeton OAuth. Mais avec un agent IA, la situation se complique : l'agent est lui-même un intermédiaire autonome qui peut enchaîner des appels vers plusieurs services tiers. Trois questions critiques se posent alors :

  1. Qui est l'humain derrière la requête de l'agent ?
  2. Comment le service tiers sait-il que cet agent agit au nom de cet humain, et pas de lui-même ou d'un attaquant ?
  3. Comment éviter qu'un jeton émis pour un service ne soit réutilisé frauduleusement auprès d'un autre ?

La spécification MCP, dans sa révision du 18 juin 2025, apporte des réponses structurées à ces questions [1] [2] [3].

Le rôle du serveur MCP : un Resource Server OAuth 2.1, rien de plus

La décision architecturale la plus importante de la révision de juin 2025 est la séparation stricte entre le serveur MCP et le serveur d'autorisation [1] [4]. Concrètement :

  • Le serveur MCP agit exclusivement comme un OAuth 2.1 Resource Server. Il ne gère ni l'authentification des utilisateurs, ni l'émission de jetons. Son rôle se limite à valider les jetons d'accès qui lui sont présentés et à appliquer le contrôle d'accès basé sur les rôles (RBAC) en interne.
  • Le serveur d'autorisation (un fournisseur d'identité externe comme Auth0, Okta, Microsoft Entra ID, Keycloak, etc.) prend en charge toute l'authentification de l'utilisateur humain et l'émission des jetons.

Cette séparation signifie que le serveur MCP n'émet jamais de jetons. Il ne fait que les recevoir, les valider, et les utiliser pour autoriser ou refuser l'accès aux outils qu'il expose [1] [3].

Le flux d'authentification : OAuth 2.1 avec PKCE et découverte automatique

Le processus se déroule en plusieurs étapes, largement automatisées grâce aux mécanismes de découverte OAuth [2] [3] :

Étape 1 — Découverte. Lorsqu'un client MCP tente d'accéder à un serveur MCP protégé sans jeton, il reçoit une réponse 401 avec un en-tête WWW-Authenticate qui pointe vers l'URL de métadonnées de ressource protégée. Le serveur MCP publie ses métadonnées au chemin /.well-known/oauth-protected-resource, conformément au RFC 9728. Ce document contient notamment un champ authorization_servers qui indique au client quel serveur d'autorisation contacter [2] [3].

{
  "resource": "https://mon-mcp-server.example.com",
  "authorization_servers": ["https://idp.example.com"],
  "scopes_supported": ["mcp:read", "mcp:tools"],
  "bearer_methods_supported": ["header"],
  "mcp_protocol_version": "2025-06-18"
}

Étape 2 — Enregistrement et autorisation. Le client MCP effectue une découverte du serveur d'autorisation via le RFC 8414 (.well-known/oauth-authorization-server), puis procède à un enregistrement dynamique de client (RFC 7591) si nécessaire. L'utilisateur humain est alors redirigé vers le flux Authorization Code avec PKCE, qui est obligatoire dans OAuth 2.1 [3] [5].

Étape 3 — Obtention du jeton. Une fois l'utilisateur authentifié et son consentement obtenu, le serveur d'autorisation émet un access token (au format JWT, conforme au RFC 9068) qui contient un claim aud (audience) correspondant à l'identifiant du serveur MCP, ainsi que des scopes spécifiques aux outils demandés [3] [6].

Étape 4 — Appel au serveur MCP. Le client MCP présente ce jeton dans l'en-tête Authorization: Bearer <token> lors de chaque requête vers le serveur MCP. Ce dernier valide systématiquement la signature, l'audience, les scopes, et la date d'expiration [3].

Le piège du Token Passthrough et l'attaque du Confused Deputy

C'est ici que le risque majeur apparaît. Imaginons que le serveur MCP, ayant reçu un jeton valide du client, ait besoin d'appeler une API tierce en aval (par exemple, une API de gestion de tickets, un système RH, etc.). L'intuition naïve serait de simplement transmettre le jeton reçu au service aval. C'est exactement ce que la spécification MCP interdit formellement [6] [7] [8].

Ce problème porte un nom : l'attaque du substitut confus (Confused Deputy Attack). Le serveur MCP devient un "député" privilégié — il détient des jetons avec des droits étendus — et un attaquant peut potentiellement le tromper pour qu'il utilise son autorité au profit d'un mauvais utilisateur ou d'une mauvaise intention. Le service aval, recevant un jeton qui n'a pas été émis pour lui, pourrait incorrectement lui faire confiance [6] [8].

La spécification est explicite : "Token passthrough is an anti-pattern where an MCP server accepts tokens from an MCP client without validating that the tokens were properly issued to the MCP server and passes them through to the downstream API" [7].

La spécification exige :

  • Que le serveur MCP valide systématiquement que le claim aud du jeton correspond à son propre identifiant ;
  • Qu'il ne transmette jamais le jeton original à un service tiers ;
  • Qu'à chaque franchissement de frontière de confiance, un échange de jeton soit réalisé [6] [7] [8].

La propagation d'identité : le Token Exchange (RFC 8693)

Pour propager l'identité de l'utilisateur humain à travers la chaîne d'appels — de l'agent, vers le serveur MCP, vers les APIs tierces — le mécanisme standard est le RFC 8693 (OAuth 2.0 Token Exchange) [9] [10] [11].

Le principe est élégant : plutôt que de transmettre un jeton existant, le serveur MCP (ou l'agent lui-même) présente son jeton courant à un serveur d'autorisation et en reçoit un nouveau, avec des caractéristiques différentes [9] [10] :

  • Une audience différente (aud) : le nouveau jeton est valide pour le service tiers visé, et uniquement pour celui-ci.
  • Un scope réduit (scope) : le nouveau jeton ne contient que les permissions strictement nécessaires à l'opération demandée (principe du moindre privilège).
  • Une chaîne de délégation explicite : le jeton porte un claim sub (le sujet — l'utilisateur humain) et un claim act (l'acteur — l'agent ou le service qui accomplit l'action) [10] [11].

Voici un exemple concret du contenu d'un tel jeton :

{
  "sub": "user@example.com",
  "aud": "https://api.tiers.example.com",
  "scope": "tickets:read",
  "act": {
    "sub": "agent-mcp-server-123",
    "act": {
      "sub": "mcp-client-456"
    }
  }
}

Dans cet exemple, le jeton dit : "L'utilisateur user@example.com a autorisé cette action. L'agent MCP numéro 123 l'exécute, suite à une demande du client MCP numéro 456" [10]. Chaque service dans la chaîne peut ainsi vérifier la chaîne de délégation, appliquer ses propres politiques d'accès, et tracer qui a fait quoi dans les journaux d'audit.

Le modèle complet : synthèse du flux sécurisé

Mettons bout à bout l'ensemble du parcours :

  1. L'utilisateur humain s'authentifie auprès du serveur d'autorisation (IdP) via le flux Authorization Code + PKCE.
  2. Le client MCP (qui peut être intégré à l'agent IA) reçoit un access token avec aud = [serveur MCP] et des scopes liés aux outils MCP.
  3. Le serveur MCP valide ce jeton à chaque requête (signature, aud, scopes, expiration).
  4. Lorsque le serveur MCP doit appeler une API tierce, il réalise un Token Exchange (RFC 8693) auprès du serveur d'autorisation : il présente son jeton et obtient en retour un nouveau jeton, scoped pour l'API tierce, portant la chaîne de délégation sub/act.
  5. L'API tierce reçoit un jeton qui lui est destiné (aud correct), qui contient l'identité de l'utilisateur original et celle de l'agent qui agit. Elle peut appliquer ses propres contrôles d'accès et journaliser l'action.

Ce modèle fonctionne également pour les chaînes multi-sauts (multi-hop) : si l'agent A délègue à l'agent B, qui délègue au serveur MCP, qui appelle une API, chaque échange de jeton ajoute un niveau de act imbriqué, préservant la chaîne complète de garde [10] [11].

Les mesures de sécurité complémentaires obligatoires

Au-delà du mécanisme de Token Exchange, la spécification MCP et les recommandations de la Coalition for Secure AI (CoSAI) imposent plusieurs contrôles [6] [7] [8] :

  • Validation d'audience systématique : Chaque serveur rejette tout jeton dont le claim aud ne correspond pas à son identifiant.
  • Consentement par client : Le serveur MCP maintient un registre des client_id approuvés par utilisateur ; un client_id inconnu déclenche un nouveau consentement explicite.
  • Scopes par outil : Depuis la révision de juin 2025, les scopes peuvent être définis au niveau de chaque outil, pas seulement globalement.
  • Rich Authorization Requests (RFC 9396) : Permet de limiter un jeton à des ressources ou paramètres d'outil spécifiques, pas seulement à de larges catégories de capacités.
  • PKCE obligatoire : Protège contre l'interception du code d'autorisation, même pour les clients confidentiels.
  • Pas d'authentification par session : L'authentification doit se faire par jeton à chaque requête, pas par état de session.
  • **Conteneurisation avec **default-deny egress : Isolement réseau du serveur MCP pour limiter le rayon d'impact en cas de compromission.
  • Journalisation liée à l'identité : Chaque action est tracée avec l'identité de l'utilisateur qui l'a déclenchée.

Les limites actuelles

Malgré cette architecture solide, plusieurs défis persistent. D'abord, selon une étude citée par la Coalition for Secure AI, seulement 18 % des déploiements de serveurs MCP implémentent une forme quelconque de scoping des permissions au niveau des outils [6]. Ensuite, le RFC 8693 a été conçu pour des échanges de jetons pair à pair, pas pour des chaînes d'agents multi-sauts avec dérive potentielle des permissions à chaque saut [12]. Des initiatives émergent pour combler ce vide, comme les preuves de délégation cryptographiques (chaînes signées Ed25519 avec des caveats (avertissements) : périmètre d'action, expiration, limites de coût), proposées par des acteurs de la communauté [13]. Microsoft propose également Entra Agent ID, qui étend le flux On-Behalf-Of avec des claims spécifiques aux agents, mais reste propriétaire [11] [14].

Enfin, un Internet-Draft (révision -02, août 2025) propose un nouveau flux OAuth de consentement en front-channel avec un acteur nommé et un claim act, qui pourrait combler les lacunes du RFC 8693 pour les scénarios purement agents [14]. Ce travail n'est pas encore adopté par l'IETF mais les concepts centraux devraient persister.

Conclusion

La garantie d'authentification et sa propagation sécurisée dans les architectures d'agents IA via MCP reposent sur un triptyque clair :

  • OAuth 2.1 avec PKCE pour l'authentification initiale de l'humain, en séparant rigoureusement le serveur MCP (Resource Server) du serveur d'autorisation (Identity Provider) ;
  • RFC 8693 (Token Exchange) pour propager l'identité à chaque saut, en émettant des jetons à audience ciblée, scopes réduits, et chaîne de délégation explicite (sub/act) ;
  • Interdiction absolue du token passthrough pour prévenir les attaques de type Confused Deputy, avec validation systématique de l'audience et consentement par client.

Ce modèle n'est pas parfait — la dérive des permissions dans les chaînes multi-sauts et le faible taux d'adoption des bonnes pratiques restent des préoccupations réelles — mais il fournit une base standardisée et auditable pour sécuriser les flux d'agents IA consommant des services tiers.

Sources