MCP et OAuth On-Behalf-Of : sécuriser vos agents Copilot Studio sans comptes admin

Un agent Copilot Studio qui appelle un serveur MCP avec un compte de service à privilèges larges est un problème de sécurité qui ne se voit qu'au moment de l'audit. La solution technique existe depuis longtemps côté identité d'entreprise : le flux OAuth 2.0 On-Behalf-Of (OBO). Appliqué aux serveurs MCP, il permet à chaque appel de s'exécuter avec les droits réels de l'utilisateur connecté, jamais avec un compte administrateur partagé.

Le problème des comptes de service dans les agents IA

La manière la plus rapide de connecter un agent Copilot Studio à une API métier consiste à créer un compte de service, lui attribuer des permissions larges sur Microsoft Graph ou sur l'API cible, puis à laisser l'agent l'utiliser pour tous les utilisateurs. Cette approche fonctionne en démonstration, mais elle pose trois problèmes en production :

• Un compromis sur ce compte donne accès à l'ensemble des données couvertes par ses permissions, pas seulement à celles d'un utilisateur.
• Il devient impossible de tracer qui, parmi les utilisateurs de l'agent, a réellement déclenché une action donnée.
• Les audits de sécurité et de conformité (RGPD, ISO 27001) exigent une traçabilité nominative que les comptes de service ne fournissent pas.

Comment fonctionne OAuth On-Behalf-Of avec MCP

Le principe d'OBO est simple : au lieu que le serveur MCP utilise ses propres credentials, il échange le jeton de l'utilisateur connecté contre un nouveau jeton, valable pour appeler l'API cible en son nom. Le flux se déroule en quatre étapes :

1. L'outil de l'agent appelle le serveur MCP via le connecteur Copilot Studio, avec le jeton de l'utilisateur signé.
2. Le serveur MCP vérifie l'identité de cet utilisateur auprès d'Entra ID.
3. Le flux OBO échange ce jeton contre un second jeton, scopé pour l'API backend (Microsoft Graph, API métier interne, etc.).
4. L'API backend répond en considérant que c'est l'utilisateur réel qui a fait la demande, jamais un compte de service.

Le résultat : Microsoft Graph (ou toute autre API compatible) ne peut physiquement pas accéder aux données d'un autre utilisateur que celui connecté, puisque le jeton porte son identité de bout en bout.

MCP vs connecteurs personnalisés classiques

Critère	Connecteur personnalisé	Serveur MCP
Protocole	REST / OpenAPI	Model Context Protocol
Découverte des outils	Schéma OpenAPI statique	Dynamique, langage naturel
Options d'authentification	OAuth, clé API	Toutes, y compris OBO
Cas d'usage idéal	API CRUD simples	Actions d'agent multi-étapes, natif IA

Bonnes pratiques de sécurité à appliquer

• Principe du moindre privilège : ne demandez que les scopes strictement nécessaires (ex. Tasks.ReadWrite plutôt qu'un accès Graph complet).
• Aucun secret dans le code source : utilisez un coffre-fort de secrets (Azure Key Vault) en production, jamais un fichier de configuration versionné.
• Validation systématique : chaque requête doit être vérifiée sur la signature, l'audience, le tenant et l'expiration du jeton.
• Permissions déléguées uniquement : évitez les permissions d'application qui donneraient à l'agent une vision transverse à tous les utilisateurs.
• Journalisation complète : chaque appel Graph doit logger l'identifiant et le nom de l'utilisateur pour la traçabilité d'audit.

Questions fréquentes

OAuth On-Behalf-Of complique-t-il le développement d'un serveur MCP ?

Non : côté implémentation .NET par exemple, une bibliothèque comme Microsoft.Identity.Web gère la validation du jeton et l'échange OBO en quelques lignes de middleware. La complexité est absorbée par la librairie, pas par le code métier.

Passer d'un environnement de test à la production nécessite-t-il une réécriture ?

Non, c'est un changement de configuration : le endpoint passe d'un tunnel de développement à un App Service, le cache de jetons passe d'une solution en mémoire à un cache distribué (Redis), mais le code d'authentification reste identique.

Cette approche s'applique-t-elle uniquement à Microsoft Graph ?

Non, OAuth OBO fonctionne avec toute API backend qui accepte les jetons Entra ID, y compris des API métier internes à l'entreprise, dès lors qu'elles sont enregistrées correctement dans le tenant.