L'authentification MCP expliquée : Identité entrante, identifiants sortants et délégation

Le jeton qui identifie un appelant auprès d'une passerelle et l'identifiant utilisé pour joindre un service en aval répondent à des problèmes différents. Les systèmes MCP sécurisés préservent cette distinction.

L'authentification ne se limite pas à un seul saut

Une requête MCP peut franchir plusieurs frontières de confiance avant d'atteindre un système métier. Une personne ou un service s'authentifie auprès d'une application. Un agent peut agir en tant que principal logiciel distinct. Le client s'authentifie auprès de MCP Gateway. La passerelle détermine si cet appelant peut utiliser un serveur ou un outil. Ensuite, la passerelle s'authentifie auprès du serveur MCP en aval, qui peut lui-même appeler un autre service faisant autorité.

Utiliser le mot « jeton » (token) pour chaque identifiant fait disparaître ces frontières. L'identifiant entrant indique qui appelle la passerelle. La politique d'accès détermine les ressources de la passerelle que cette identité peut utiliser. L'authentification sortante définit les identifiants et permissions reçus par le serveur en aval. Ces réponses peuvent être intentionnellement différentes.

La documentation de TrueFoundry divise l'architecture en trois parties : l'authentification entrante, le contrôle d'accès et l'authentification sortante. Cette séparation constitue le bon point de départ pour analyser la délégation, l'attribution et le risque de député confus (confused deputy).

La passerelle effectue intentionnellement trois vérifications distinctes. Une authentification entrante réussie identifie un appelant, mais la politique d'accès sélectionne toujours les outils autorisés et l'authentification sortante détermine toujours le principal vu par le serveur MCP.

L'authentification entrante identifie l'appelant de la passerelle

TrueFoundry documente plusieurs méthodes entrantes : un jeton d'accès personnel (personal access token) pour les utilisateurs possédant un compte TrueFoundry, un jeton de compte virtuel (virtual-account token) pour les appels de service à service, un jeton de fournisseur d'identité pour les clients ou services utilisant l'émetteur JWT d'une organisation, et TrueFoundry OAuth pour les clients IDE compatibles.

Après avoir validé l'identifiant, la passerelle identifie une identité TrueFoundry et applique le contrôle d'accès aux serveurs MCP et aux outils individuels. L'identité concernée peut être un utilisateur, une équipe ou un compte virtuel. Agent Identity, documenté en version bêta, ajoute un acteur d'agent enregistré distinct pour les appels émis par des agents. Cela diffère d'un compte virtuel, qui représente un service ou une application sans intervention humaine.

La résolution d'identité doit valider l'émetteur, l'audience, la signature, les limites temporelles et le mappage de claims utilisé pour sélectionner le sujet. Un jeton valablement signé pour la mauvaise audience ne constitue pas une autorité valable pour la passerelle. Les mappages doivent être suffisamment spécifiques pour éviter que deux services ne soient attribués par erreur à la même identité d'agent.

L'authentification sortante sélectionne le principal en aval

La passerelle peut s'authentifier auprès d'un serveur MCP à l'aide d'un code d'autorisation OAuth par utilisateur, d'identifiants client OAuth au niveau de l'application, de la configuration Okta documentée d'échange de jetons/OBO, de clés API partagées ou individuelles, d'aucune authentification pour les services publics, du passthrough de jeton, du transfert de jeton (token forwarding) ou de AWS SigV4 pour les points de terminaison AWS pris en charge.

Ces modes définissent des niveaux d'autorité différents. OAuth par utilisateur permet à chaque personne d'autoriser son propre compte tiers. Les identifiants client représentent l'application et exposent généralement des permissions de service partagées. L'échange de jetons ou OBO demande à un système d'identité de générer un nouveau jeton en aval dérivé de l'identité de l'appelant et ciblant une autre audience. Une clé API partagée regroupe tous les appelants sous un seul principal en amont, même si la passerelle conserve une attribution interne.

Choisir l'intégration la plus simple peut modifier silencieusement le modèle d'autorisation. Si un serveur MCP Gmail utilise un seul identifiant de service partagé, le service en amont ne verra pas l'autorité de la boîte aux lettres personnelle de chaque employé. Si un serveur MCP interne valide directement le jeton du fournisseur d'identité de l'organisation, le passthrough peut préserver le sujet — mais seulement si l'émetteur, l'audience et les portées (scopes) sont acceptés de manière délibérée.

Le schéma regroupe les modes selon la sémantique d'autorité plutôt que selon les labels de protocole. Les flux par utilisateur et OBO peuvent préserver le contexte du sujet, tandis que les identifiants client et les clés partagées représentent l'autorité applicative, à moins que le service en aval n'applique des contrôles supplémentaires tenant compte du sujet.

Passthrough et forwarding ne sont pas synonymes

Dans la terminologie documentée de TrueFoundry, le passthrough de jeton transmet le jeton utilisé pour l'authentification entrante directement au serveur MCP. Le serveur doit être capable de valider ce jeton TrueFoundry ou du fournisseur d'identité. Le transfert de jetons (token forwarding) achemine des identifiants spécifiques au serveur fournis par le client dans des en-têtes dédiés. L'identifiant sortant n'est pas le porteur (bearer) entrant.

Cette distinction est essentielle pour la journalisation, la rédemption (redaction), la révocation et la modélisation des menaces. Le passthrough conserve un seul identifiant à travers la frontière de la passerelle et exige donc une confiance correcte dans l'audience en aval. Le forwarding introduit un autre secret que le client doit obtenir et protéger. Ni l'un ni l'autre ne garantit automatiquement qu'une API métier finale a validé la relation prévue entre l'humain et l'agent.

L'échange de jetons OAuth et l'OBO offrent un schéma différent : la passerelle ou la couche d'identité obtient un nouveau jeton spécifique à l'audience, représentant une autorité déléguée. Cela permet de réduire la réutilisation des jetons porteurs et permet aux systèmes en aval d'appliquer des portées conçues pour leurs ressources. Les garanties exactes dépendent du fournisseur d'identité, des claims, de la validation et de l'application en aval.

Modélisez les principaux, pas seulement les en-têtes

Éviter le problème du député confus

Une passerelle devient un député confus (confused deputy) lorsqu'elle dispose d'une autorité étendue en aval et l'utilise pour un appelant qui ne possède pas les permissions équivalentes. L'authentification entrante peut être parfaitement valide alors que l'action composée reste sur-autorisée. La passerelle doit recouper l'identité de l'appelant, l'identité de l'agent, le serveur et l'outil demandés, le mode d'identifiant sortant et la portée en aval.

Pour les identifiants partagés, le serveur MCP ou l'application sous-jacente doit recevoir suffisamment de contexte de confiance pour réappliquer une autorisation prenant en compte le sujet, ou bien l'outil ne doit exposer que des ressources sans risque pour tous les appelants autorisés. Ne comptez pas sur le modèle pour filtrer les résultats après une requête large. Pour les identifiants par utilisateur, vérifiez que l'autorisation est liée au sujet visé et ne peut pas être substituée par un autre utilisateur via des surcharges (overrides).

Chaque saut doit également conserver un identifiant de corrélation d'audit sans copier les jetons porteurs dans les journaux. Enregistrez le mode d'identifiant, l'identité résolue, l'émetteur, l'audience, la classe de portée, la version de la politique et les métadonnées de réponse en aval. Les secrets doivent être conservés dans des coffres sécurisés, et non dans des transcriptions ou des traces.

La chaîne transporte à la fois un sujet humain et un acteur logiciel à travers la décision de la passerelle. Le mode sortant peut préserver, échanger ou réduire ce contexte d'identité ; le système en aval effectue toujours l'autorisation finale sur la ressource et l'action.

Exemple concret : accès CRM du support client

Un agent du support reçoit une requête de la part d'un employé authentifié. L'application envoie le jeton du fournisseur d'identité de l'employé à MCP Gateway et présente séparément l'identité d'agent enregistrée. La politique de la passerelle autorise cette paire utilisateur-agent à appeler l'outil de recherche du CRM.

Imaginons que le déploiement utilise la configuration Okta OBO documentée de TrueFoundry. La passerelle échange le jeton utilisateur entrant contre un jeton destiné au CRM avec une portée de lecture seule sur les tickets. Le CRM valide le nouveau jeton et applique sa propre autorisation au niveau des lignes. L'agent peut récupérer les tickets autorisés de l'employé, mais ne peut pas les modifier. Un outil de mise à jour distinct nécessiterait une portée en aval plus restreinte et une approbation.

Si le déploiement utilise plutôt une clé API partagée, l'architecture doit compenser. Le service faisant face au CRM reçoit un attribut de sujet résolu et de confiance de la part de la passerelle, le valide et filtre les enregistrements côté serveur. Si le service ne peut pas appliquer ce contexte de sujet, la clé partagée ne convient pas pour des données nécessitant une autorisation spécifique à l'utilisateur.

Choisir l'authentification sortante selon la sémantique d'autorité

• Utilisez l'autorisation par utilisateur lorsque la ressource en amont appartient à chaque personne ou dépend de ses permissions.
• Utilisez les identifiants client pour les ressources appartenant réellement à l'application, et non comme un raccourci pour contourner l'autorisation utilisateur.
• Utilisez l'échange de jetons ou OBO lorsque le système en aval a besoin d'un jeton utilisateur délégué et spécifique à une audience.
• N'utilisez le passthrough que si le système en aval fait confiance et valide délibérément le jeton entrant.
• Utilisez le forwarding lorsque le serveur MCP possède un schéma d'identifiants séparé et acceptez la charge de gestion des secrets clients qui en découle.
• Traitez les serveurs sans authentification comme des capacités publiques ; ne placez pas de données sensibles ou de mutations derrière eux.

Tests de défaillance pour la chaîne d'authentification

• Rejouez un jeton valide avec une mauvaise audience, un mauvais émetteur, un mauvais tenant ou un mauvais sujet mappé.
• Conservez le même utilisateur et modifiez l'identité de l'agent ; vérifiez que la portée effective de l'outil change comme prévu.
• Conservez le même agent et modifiez l'utilisateur ; vérifiez que les données en aval suivent le sujet humain si nécessaire.
• Substituez un identifiant individuel en utilisant la surcharge d'authentification (auth override) d'un autre utilisateur.
• Réviquez indépendamment un accès passerelle et une autorisation OAuth en amont ; vérifiez leurs effets distincts.
• Appelez le serveur MCP en dehors de la passerelle ; vérifiez que la politique réseau et du serveur empêche un contournement si nécessaire.
• Inspectez les journaux, traces, erreurs et le contexte du modèle pour détecter d'éventuelles fuites de jetons porteurs ou de secrets transférés.

Le cycle de vie des identifiants fait partie du parcours des données

La conception de l'authentification se poursuit après l'acceptation d'un jeton. Les identifiants expirent, se rafraîchissent, tournent (rotation) et sont révoqués sur différents systèmes. La documentation de TrueFoundry précise, par exemple, que son action « Revoke all tokens » supprime les identifiants stockés dans AI Gateway mais ne révoque pas les autorisations auprès du fournisseur OAuth en amont. Les équipes de support ont besoin de procédures distinctes pour l'identifiant de la passerelle, la session du fournisseur d'identité, l'autorisation en amont et tout jeton mis en cache en aval.

Définissez quel composant rafraîchit chaque identifiant, quel sujet représente le jeton rafraîchi et ce qui se passe si le rafraîchissement échoue au milieu d'une tâche d'agent. Un flux d'autorisation suspendu ne doit pas basculer silencieusement sur un identifiant applicatif disposant d'un accès plus large. Lorsque l'utilisateur reconnecte un compte, la nouvelle autorisation doit être associée au sujet et au serveur visés avant que l'agent ne poursuive son exécution.

La rotation crée une autre limite à tester. Les clés API partagées peuvent nécessiter une période de transition à deux clés ; les jetons OAuth par utilisateur peuvent être invalidés indépendamment ; les jetons OBO peuvent être mis en cache jusqu'à leur expiration tandis que le jeton entrant doit rester valide pour un nouvel échange. Stockez les identifiants de mode d'authentification et de famille de jetons dans des métadonnées d'exploitation protégées afin que les équipes d'intervention puissent identifier les appels impactés sans exposer de secrets.

La révocation doit être vérifiée de l'extérieur vers l'intérieur. Supprimez le collaborateur de la passerelle, révoquez l'autorisation en amont, désactivez le compte en aval et testez chaque effet séparément. Une procédure d'incident complète permet de savoir quelle action bloque les nouveaux appels vers la passerelle, laquelle invalide l'accès direct et laquelle ne fait que supprimer une copie locale.

La manipulation des jetons doit également être absente du contexte visible par le modèle. Les agents peuvent raisonner sur des identifiants stables, des résultats d'autorisation et des instructions de reconnexion sans recevoir de jetons porteurs. Les erreurs renvoyées par les fournisseurs doivent être normalisées afin que les sorties de débogage ne diffusent pas d'en-têtes, de jetons de rafraîchissement, de secrets client ou de composants de requête signés dans la transcription.

La règle opérationnelle

Une authentification MCP sécurisée commence par l'identification de chaque principal et de chaque saut. L'identité entrante, l'accès à la passerelle, l'identifiant sortant et l'autorisation métier sont des contrôles liés mais non interchangeables. La conception la plus sûre rend explicite tout changement de principal ou d'audience.

TrueFoundry MCP Gateway fournit des mécanismes documentés pour chaque couche faisant face à la passerelle, et Agent Identity — documenté en bêta dans la carte de disponibilité de la gouvernance — permet de distinguer l'acteur logiciel du sujet humain. L'application en aval conserve la responsabilité de son autorisation de domaine et l'organisation conserve celle de la minimisation des identifiants. Cette frontière n'est pas une limitation de ce modèle : c'est ce qui rend son modèle de sécurité vérifiable.

Références

1. TrueFoundry — MCP Gateway Authentication and Security.
2. TrueFoundry — Agent Identity.
3. TrueFoundry — MCP Gateway Overview.
4. IETF RFC 8693 — OAuth 2.0 Token Exchange.

Mentions éditoriales. Cet article reflète l'interprétation technique par TrueFoundry des documents publics cités au 17 septembre 2026. Les fonctionnalités du produit sont limitées à la documentation associée. Les exemples et les configurations par défaut sont fournis à titre d'illustration ; ils ne constituent pas un conseil juridique, un avis d'audit, un benchmark indépendant ou une garantie de sécurité, de fiabilité ou de conformité.

‍