AWS a montré comment connecter des serveurs MCP protégés par OAuth à Bedrock AgentCore Gateway

AWS a montré comment connecter des serveurs MCP protégés par OAuth à Amazon Bedrock AgentCore Gateway via le flux Authorization Code. Le scénario est conçu pour les équipes qui ont besoin d'une authentification unique pour les agents IA dans les outils d'entreprise sans jetons intégrés et sans configuration manuelle de chaque intégration.

Pourquoi Amazon Bedrock AgentCore Gateway est Nécessaire

AWS positionne le Gateway comme le point central par lequel les agents et les clients MCP accèdent aux outils à l'intérieur de l'entreprise. Au lieu de configurer chaque serveur MCP séparément dans un IDE, l'équipe peut fournir aux développeurs une seule URL Gateway et des règles d'accès unifiées. AWS transfère l'authentification, l'observabilité et le contrôle des politiques d'accès à cette couche pour que les connexions aux outils ne se transforment pas en un ensemble de configurations manuelles dispersées.

C'est particulièrement pertinent pour les entreprises où les serveurs MCP se multiplient : services internes propres, GitHub, Salesforce, Databricks et autres systèmes externes. Beaucoup de ces serveurs sont protégés par OAuth 2.0 et exigent que l'agent agisse au nom d'un utilisateur spécifique.

Dans ce schéma, le Gateway soulage les applications du travail supplémentaire : il n'est pas nécessaire d'intégrer les identifiants dans le code, de mettre à jour les jetons indépendamment ou de répéter la même logique pour chaque connecteur.

Deux Modes de Connexion

Dans l'article, AWS montre deux façons de connecter un serveur MCP protégé par OAuth au Gateway. La première est la synchronisation implicite lors de la création d'une cible : l'administrateur passe par le flux Authorization Code lors de CreateGatewayTarget, UpdateGatewayTarget ou SynchronizeGatewayTargets, après quoi le Gateway lit la liste des outils et la met en cache. La seconde est de fournir le schéma des outils à l'avance sans attendre une demande en direct au serveur lors de la création de la cible. AWS nomme directement la deuxième option comme préférée dans les cas où la participation humaine à la création ou à la mise à jour n'est pas possible.

• La synchronisation implicite exige que l'administrateur complète l'autorisation et accorde au Gateway l'accès au serveur MCP déjà au stade de la configuration.
• Le schéma prédéfini permet d'insérer immédiatement la liste des outils et d'obtenir une cible prête sans autorisation lors de la création.
• En mode avec schéma prédéfini, vous ne pouvez pas utiliser SynchronizeGatewayTargets, car le Gateway s'appuie sur la description fournie plutôt que sur la lecture en direct du serveur.
• Les utilisateurs du Gateway peuvent effectuer tools/list sans se connecter à chaque serveur, car les définitions des outils sont déjà en cache.
• L'autorisation n'est déclenchée que lorsque l'utilisateur appelle réellement l'outil nécessaire via tools/call.

Par exemple, AWS utilise le serveur MCP de GitHub. Pour un tel scénario, vous avez besoin d'un Gateway sur la version MCP 2025-11-25 ou plus récente, sinon l'option Authorization code grant 3LO ne sera pas disponible. La configuration spécifie également l'URL de retour : c'est là que l'utilisateur ou l'administrateur revient après l'écran de consentement, et l'application complète alors l'échange via CompleteResourceTokenAuth.

Comment Fonctionne l'Autorisation

La partie clé du schéma est la liaison entre AgentCore Gateway et AgentCore Identity. D'abord, le Gateway obtient un jeton d'accès de charge de travail, confirmant qu'il a le droit de demander des identifiants au nom de sa charge de travail. Ensuite, via un fournisseur d'identifiants, il reçoit soit un jeton d'accès prêt, soit l'URL d'autorisation et l'URI de session si un jeton n'a pas encore été émis pour un utilisateur particulier. Au stade de la configuration initiale de la cible, cela peut entraîner un statut Needs authorization, et après avoir complété le consentement, passer à Ready avec le label Authorized.

AWS souligne séparément URL session binding. Le mécanisme vérifie que l'autorisation a été initiée et complétée par le même utilisateur, et non par quelqu'un qui a accidentellement reçu un lien renvoyé. Après consentement, le navigateur revient au callback, l'application transmet l'URI de session et l'identité de l'utilisateur à CompleteResourceTokenAuth, et ce n'est qu'après cette vérification que l'échange du code d'autorisation contre un jeton d'accès se produit. Selon AWS, le lien d'autorisation et l'URI de session durent 10 minutes, ce qui réduit encore la fenêtre pour les abus.

Pour l'utilisateur final, la logique est plus simple. La demande tools/list est servie à partir du cache du Gateway et ne vous oblige pas à vous connecter à tous les systèmes connectés à l'avance. Mais tools/call initie déjà le flux Authorization Code uniquement pour ce serveur MCP dont l'outil est réellement appelé. Après une connexion réussie, le jeton est mis en cache dans le Token Vault dans la liaison d'identité de charge de travail et d'identité utilisateur, les appels ultérieurs se font donc sans nouvelle autorisation tant que le jeton reste valide.

Ce Que Cela Signifie

AWS fait passer MCP d'un ensemble d'intégrations ponctuelles à une couche d'entreprise gérée. Pour les équipes qui construisent des systèmes d'agents sur plusieurs outils externes et internes, cela réduit le chaos dans les accès : le catalogue des outils peut être affiché de manière centralisée, et l'autorisation utilisateur ne peut être activée qu'au moment de l'invocation réelle du serveur nécessaire.