Amazon Bedrock AgentCore Gateway proporciona una capa centralizada para administrar cómo los agentes de IA se conectan a herramientas y servidores MCP en toda su organización. Consolida la autenticación, la observabilidad y la aplicación de políticas en un único punto final, eliminando la necesidad de configurar y proteger cada conexión del servidor MCP individualmente.
En esta publicación, explicamos cómo configurar AgentCore Gateway para conectarse a un servidor MCP protegido por OAuth mediante el flujo del Código de autorización.
Uso de AgentCore Gateway como punto final del servidor MCP
A medida que las organizaciones escalan sus implementaciones de agentes de IA, la cantidad de servidores MCP en los que depende cada equipo crece rápidamente. Los desarrolladores están adoptando Amazon Bedrock AgentCore Gateway como un punto final único para acceder a múltiples servidores MCP. En lugar de configurar cada servidor MCP individualmente por IDE, los equipos apuntan a una URL de puerta de enlace para obtener acceso consistente a su conjunto completo de herramientas MCP en todas las herramientas.
Este patrón se está acelerando a medida que los equipos van más allá de los servidores MCP personalizados y adoptan servidores de terceros de nivel de producción, como los de AWS, GitHub, Salesforce y Databricks. Muchos de estos servidores MCP están protegidos por su proveedor de identidad principal a través de la federación, mientras que otros están protegidos por sus propios servidores de autorización. A medida que crece el número de servidores MCP por organización, la gestión de conexiones, autenticación y enrutamiento a nivel de IDE se vuelve insostenible. AgentCore Gateway centraliza esta complejidad, brindando a los equipos un plano de control único para el acceso a MCP y al mismo tiempo brinda a los desarrolladores una experiencia sin fricciones.
Muchos servidores MCP empresariales requieren autorización OAuth 2.0, donde el agente debe autenticarse en nombre de un usuario antes de invocar herramientas. AgentCore Gateway ahora admite el flujo del código de autorización OAuth 2.0 a través de Amazon Bedrock AgentCore Identity. Con esto, sus agentes pueden acceder de forma segura a servidores MCP protegidos sin insertar credenciales en el código de la aplicación ni administrar el ciclo de vida del token manualmente.
Términos clave
Usuario de AgentCore Gateway: el usuario final que consume las herramientas en Amazon Bedrock AgentCore Gateway con clientes MCP. Los usuarios de la puerta de enlace no administran la puerta de enlace AgentCore en sí. Utilizan la única URL de AgentCore Gateway para acceder a las herramientas disponibles para ellos. Usuario administrador: el usuario que administra y mantiene Amazon Bedrock AgentCore Gateway. Este usuario es responsable de conectar servidores, herramientas o API de MCP a AgentCore Gateway para que los usuarios de AgentCore Gateway puedan consumirlos. Servidor MCP: en esta publicación, asumimos que el servidor MCP está protegido por un flujo de código de autorización OAuth 2.0, que requiere la interacción del usuario para completar la autenticación. Esto se diferencia de los métodos de autenticación de máquina a máquina, como las credenciales de cliente o el intercambio de tokens, donde no se requiere la intervención del usuario. Los patrones descritos en esta publicación se aplican específicamente a servidores MCP que requieren autorización delegada por el usuario.
Cómo funciona el flujo del código de autorización
Para brindar soporte para el tipo de concesión de código de autorización, ofrecemos dos formas de creación de objetivos.
Sincronización implícita durante la creación del objetivo del servidor MCP
En este método, el usuario administrador completa el flujo del código de autorización durante las operaciones CreateGatewayTarget, UpdateGatewayTarget o SynchronizeGatewayTargets. Esto permite a AgentCore Gateway descubrir y almacenar en caché las herramientas del servidor MCP por adelantado.
Proporcionar un esquema por adelantado durante la creación de objetivos del servidor MCP
Con este método, los usuarios administradores proporcionan el esquema de la herramienta directamente durante las operaciones CreateGatewayTarget o UpdateGatewayTarget, en lugar de que AgentCore Gateway los obtenga dinámicamente desde el servidor MCP. AgentCore Gateway analiza el esquema proporcionado y almacena en caché las definiciones de herramientas. Esto elimina la necesidad de que el usuario administrador complete el flujo del código de autorización durante la creación o actualización del objetivo. Este es el enfoque recomendado cuando la intervención humana no es posible durante las operaciones de creación/actualización. Este método es beneficioso cuando no desea exponer todas las herramientas proporcionadas por el servidor MCP de destino.
Nota: Debido a que los esquemas de herramientas se proporcionan por adelantado con este método, no se admite la operación SynchronizeGatewayTargets. Puede cambiar un objetivo entre el Método 1 y el Método 2 actualizando la configuración del objetivo.
Esto significa que los usuarios de AgentCore Gateway pueden llamar a la lista/herramientas sin que se les solicite que se autentiquen con el servidor de autenticación del servidor MCP, porque esto recupera las herramientas almacenadas en caché. El flujo del código de autorización solo se activa cuando un usuario de Gateway invoca una herramienta en ese servidor MCP. Esto es particularmente beneficioso cuando hay varios servidores MCP conectados a una única puerta de enlace. Los usuarios pueden explorar el catálogo completo de herramientas (herramientas almacenadas en caché) sin autenticarse en cada servidor MCP y solo completar el flujo para el servidor específico cuya herramienta invocan.
Enlace de sesión URL
El enlace de sesión de URL verifica que el usuario que inició la solicitud de autorización de OAuth es el mismo usuario que otorgó el consentimiento. Cuando AgentCore Identity genera una URL de autorización, también devuelve un URI de sesión. Una vez que el usuario completa su consentimiento, el navegador redirige a una URL de devolución de llamada con el URI de sesión. Luego, la aplicación es responsable de llamar a la API CompleteResourceTokenAuth, presentando tanto la identidad del usuario como el URI de sesión. AgentCore Identity valida que el usuario que inició el flujo es el mismo usuario que lo completó antes de intercambiar el código de autorización por un token de acceso. Esto ayuda a evitar una situación en la que un usuario comparte accidentalmente la URL de autorización y otra persona completa el consentimiento, lo que otorgaría tokens de acceso a la parte equivocada. La URL de autorización y la URI de sesión solo son válidas durante 10 minutos, lo que limita aún más la ventana de uso indebido. El enlace de sesión se aplica durante la creación del objetivo de administrador (sincronización implícita) y durante la invocación de la herramienta.
Descripción general de la solución
En esta publicación, mostramos cómo conectar el servidor GitHub MCP a Amazon Bedrock AgentCore Gateway mediante el Método 1 (sincronización iniciada por el administrador durante la creación del objetivo) y el Método 2 (proporcionar el esquema de la herramienta por adelantado durante la creación del objetivo). El código adjunto está disponible en este repositorio.
Requisitos previos
Debe seguir los siguientes requisitos previos junto con esta publicación.
Configuración de aplicaciones GitHub OAuth Vaya a https://github.com/settings/apps → Nueva aplicación GitHub
Complete los detalles: Nombre de la aplicación GitHub: AgentCore Gateway URL de la página de inicio de GitHub MCP (la URL completa del sitio web de su aplicación GitHub): La URL de la página de inicio aparece como un enlace en el que se puede hacer clic cuando el usuario ve su aplicación OAuth, lo que le permite obtener más información sobre su aplicación. Ayuda a los usuarios a verificar la legitimidad de la aplicación que solicita acceso a su cuenta de GitHub. URL de devolución de llamada de autorización: La URL de devolución de llamada de autorización (URI de redireccionamiento) es la URL a la que GitHub redirige al usuario después de que autoriza (o deniega) su aplicación OAuth. Por ahora, pongamos https://example.com/auth, volveremos y cambiaremos este valor. Configuración avanzada: aquí repasamos los valores predeterminados recomendados. Sin embargo, asegúrese de seguir las mejores prácticas de seguridad basadas en las políticas de su organización. Caducar tokens de autorización de usuario: Desactivar: si está habilitado, esto permitirá que AgentCore Identity actualice automáticamente los tokens para el usuario. Solicitar autorización de usuario (OAuth) durante la instalación: Desactivar. Flujo de dispositivos: Desactivar: permite la autorización en dispositivos que no tienen un navegador (por ejemplo, herramientas CLI, televisores inteligentes, entornos CI). Webhook: Desactivar. Permisos de usuario: dependen del caso de uso, manténgalos predeterminados por ahora: se otorgan cuando el usuario pasa por el flujo de autorización de OAuth. Solicite solo lo que necesite, los usuarios ven estos permisos en la pantalla de consentimiento y los permisos excesivos reducen la confianza. Elija Crear aplicación GitHub. Asegúrese de anotar el ID de cliente de la aplicación (diferente al ID de la aplicación). En la configuración general de su aplicación Oauth, elija Generar un nuevo secreto de cliente. Asegúrese de anotar el secreto del cliente, ya que GitHub solo lo muestra una vez al crearlo. Permisos de IAM: necesita permisos de IAM adecuados para ejecutar el código de esta publicación de blog. Estos son los permisos mínimos de IAM requeridos. Repositorio de código: primero clone el repositorio de GitHub y luego abra github-mcp-server.ipynb. Recomendamos seguir las instrucciones de la consola en esta publicación de blog para comprender los conceptos y luego consultar el tutorial del código.
Proveedor de credenciales de GitHub: en este paso configuraremos el proveedor de credenciales de identidad Agentcore. En la consola de Amazon Bedrock AgentCore, vaya a AgentCore Identity y cree un cliente OAuth. 
Proporcione un nombre para el cliente OAuth, elija el proveedor de GitHub incluido y complete el ID de cliente y el secreto del cliente de la aplicación GitHub OAuth. Copie la URL de devolución de llamada del cliente AgentCore Identity OAuth y asegúrese de volver al proveedor de GitHub OAuth que creó y actualice la URL de devolución de llamada de autorización.
Sincronización implícita durante la creación del objetivo del servidor MCP
En esta sección, presentaremos cómo funciona la sincronización implícita durante la creación del objetivo del servidor MCP. Asegúrese de que la función de ejecución de AgentCore Gateway tenga permisos GetWorkloadAccessTokenForUserId y CompleteResourceTokenAuth. Primero, comencemos por comprender el flujo.
El usuario administrador llama a CreateGatewayTarget y proporciona el punto final del servidor MCP, el proveedor de credenciales de identidad AgentCore y la URL de retorno. Esto le indica a AgentCore Gateway a qué servidor MCP conectarse y qué proveedor de credenciales usar para obtener tokens OAuth 2.0. Este mismo flujo también se aplica a las operaciones UpdateGatewayTarget y SynchronizeGatewayTargets. AgentCore Gateway solicita un token de acceso a la carga de trabajo del proveedor de credenciales de identidad de AgentCore, pasando la identidad de la carga de trabajo de AgentCore Gateway y un ID de usuario en el formato {gatewayId}{targetId}{uuid}. Este token de acceso a la carga de trabajo identifica AgentCore Gateway como una persona que llama autorizada para operaciones de credenciales posteriores. Al utilizar el token de acceso a la carga de trabajo, AgentCore Gateway solicita un token de acceso OAuth 2.0 al proveedor de credenciales de identidad de AgentCore. Esto proporciona al usuario administrador una URL de autorización y un URI de sesión. En esta etapa, el objetivo se encuentra en el estado Necesita autorización. El administrador abre la URL de autorización en su navegador, inicia sesión y otorga los permisos solicitados a AgentCore Gateway. Después de que el administrador otorga su consentimiento, el servidor de autorización OAuth 2.0 envía un código de autorización al punto final de devolución de llamada registrado del proveedor de credenciales de identidad AgentCore. El proveedor de credenciales redirige el navegador de administración a la URL de retorno, con el URI de sesión. La aplicación de administración llama a CompleteResourceTokenAuth y presenta la identificación de usuario y el URI de sesión devuelto en el paso 2. El proveedor de credenciales valida que el usuario que inició el flujo de autorización (paso 3) es el mismo usuario que completó el consentimiento. Esto evita el secuestro de tokens si la URL de autorización se compartió accidentalmente. Si el flujo se inició desde la consola de AWS, este paso se maneja automáticamente. Si se inicia desde otro contexto, el administrador es responsable de llamar directamente a la API CompleteResourceTokenAuth. Después de una validación de enlace de sesión exitosa, el proveedor de credenciales intercambia el código de autorización con el servidor de autorización de OAuth 2.0 por un token de acceso de OAuth 2.0. Este token de acceso se utiliza para enumerar las herramientas en el destino del servidor MCP; Las definiciones de herramientas devueltas desde el destino se almacenan en caché en AgentCore Gateway.
Tenga en cuenta que una actualización o sincronización posterior con el destino no reutilizará el token de acceso. En cambio, AgentCore Identity obtendrá un nuevo token de acceso del servidor de autorización.
Creación de objetivos
Primero, comencemos creando una puerta de enlace y un destino Amazon Bedrock AgentCore y veamos cómo funciona la sincronización implícita durante la creación del destino del servidor MCP.
Al crear una puerta de enlace AgentCore, debe utilizar la versión de MCP 2025-11-25 o posterior. Mantenga todo lo demás predeterminado y seleccione el destino del servidor MCP. Proporcione el punto final del servidor MCP y, para el cliente OAuth, seleccione el cliente AgentCore Identity OAuth creado durante la sección de requisitos previos.
En configuración adicional, asegúrese de seleccionar Concesión de código de autorización (3LO). La opción de concesión de código de autorización (3LO) se desactivará si AgentCore Gateway no se creó con la versión de MCP 2025-11-25 o posterior. Aquí también debes proporcionar la URL de retorno. Durante el proceso de vinculación de la sesión después del flujo del código de autorización, los usuarios volverán a esta URL, tanto durante la sincronización implícita como durante la invocación de la herramienta. Puede anular el valor de la URL de retorno durante la invocación. Para obtener más información, consulte Ejemplo: concesión de código de autorización en la Guía para desarrolladores de Amazon Bedrock AgentCore. Puede proporcionar ámbitos y parámetros adicionales, como audiencia, al configurar el objetivo. Estos parámetros se incluyen en la solicitud cuando AgentCore Identity llega al punto final /authorize del servidor de autorización.
Después de crear el objetivo, el objetivo estará en el estado Necesita autorización. En este punto, los usuarios administradores deben completar la solicitud de autorización, ya sea directamente desde la consola de AWS o navegando directamente a la URL de autorización. Es importante tener en cuenta que si el flujo se completa desde la consola de AWS, el enlace de sesión se maneja automáticamente. Si se inicia desde otro contexto, el administrador es responsable de llamar directamente a la API CompleteResourceTokenAuth. Para obtener más información, consulte el ejemplo de código en GitHub.
Así es como se ve el flujo de consentimiento cuando se inicia desde la consola de AWS.
Después de unos segundos, verá que el objetivo está en estado Listo con estado de autorización Autorizado.
Proporcionar un esquema por adelantado durante la creación de objetivos del servidor MCP
En esta sección, presentamos cómo proporcionar el esquema por adelantado durante la creación de objetivos del servidor MCP. Este es el enfoque recomendado cuando la intervención humana no es posible durante las operaciones de creación/actualización.
En este paso, creamos una puerta de enlace y un destino Amazon Bedrock AgentCore y proporcionamos un esquema por adelantado durante la creación de los destinos del servidor MCP. El proceso sigue siendo el mismo. Durante la selección de creación de destino, seleccione Usar herramientas de lista predefinidas y pegue las definiciones de las herramientas de GitHub. Puede copiar la definición de la herramienta desde el repositorio de GitHub.
En este caso, el objetivo queda listo inmediatamente y tiene el estado de autorización No se requiere autorización.
Manifestación
Después de la creación exitosa del objetivo, ya sea utilizando el método de sincronización implícita o proporcionando el esquema por adelantado, los usuarios de AgentCore Gateway pueden descubrir e invocar herramientas utilizando el protocolo MCP. En esta sección, analizamos las herramientas/lista y las herramientas/flujos de llamadas de AgentCore Gateway.
El usuario de la puerta de enlace envía una solicitud de lista/herramientas a AgentCore Gateway con su token de autorización entrante. Debido a que las definiciones de herramientas se almacenaron en caché durante la creación del destino, AgentCore Gateway devuelve las definiciones de herramientas almacenadas en caché inmediatamente. El usuario de la puerta de enlace envía herramientas/solicitud de llamada a AgentCore Gateway con su token de autorización entrante. Esto activa el flujo del código de autorización OAuth para el destino del servidor MCP específico, porque AgentCore Gateway necesita un token de acceso para llamar al servidor MCP en nombre de este usuario. AgentCore Gateway solicita un token de acceso a la carga de trabajo de AgentCore Identity, pasando la identidad de la carga de trabajo y el JWT del usuario desde el encabezado de autorización entrante. Al utilizar el token de acceso a la carga de trabajo, AgentCore Gateway solicita un token de acceso OAuth 2.0 al proveedor de credenciales. Como todavía no existe ningún token válido para este usuario, el proveedor de credenciales devuelve una URL de autorización y un URI de sesión. AgentCore Gateway devuelve la URL de autorización y el URI de sesión al usuario de la puerta de enlace. El usuario abre la URL de autorización en su navegador, inicia sesión en el servidor de autorización OAuth 2.0 y otorga los permisos solicitados. La respuesta de obtención de URL de muestra de AgentCore Gateway es la siguiente:
Después de que el usuario otorga su consentimiento, el servidor de autorización OAuth 2.0 envía un código de autorización al punto final de devolución de llamada registrado del proveedor de credenciales de identidad AgentCore. El proveedor de credenciales redirige el navegador del usuario a la URL de retorno con el URI de sesión. La aplicación del usuario llama a CompleteResourceTokenAuth y presenta el JWT del usuario y el URI de sesión. El proveedor de credenciales valida que el usuario que inició el flujo de autorización (Paso 4) es el mismo usuario que completó el consentimiento. Después de una validación de enlace de sesión exitosa, el proveedor de credenciales intercambia el código de autorización con el servidor de autorización de OAuth 2.0 por un token de acceso de OAuth 2.0. El proveedor de credenciales almacena en caché este token en Token Vault bajo la identidad de carga de trabajo y la identidad de usuario. Cuando el usuario de la puerta de enlace vuelve a emitir una solicitud de llamada/herramientas, AgentCore Gateway obtiene el token almacenado en caché, utilizando la identidad de la carga de trabajo y la identidad del usuario, de AgentCore Identity y lo utiliza para llamar al servidor MCP.
Veamos ahora una demostración del flujo de un extremo a otro donde enviamos herramientas/listas y herramientas/solicitudes de llamadas a AgentCore Gateway.
Limpiar
Cuando haya terminado de usar esta solución, asegúrese de limpiar todos los recursos. Siga las instrucciones en el repositorio de código.
Conclusión
En esta publicación, demostramos cómo conectar un servidor MCP protegido por OAuth a Amazon Bedrock AgentCore Gateway mediante el flujo del Código de autorización. Al centralizar la autenticación a través de AgentCore Gateway, los equipos pueden administrar las credenciales de forma segura utilizando Amazon Bedrock AgentCore Identity y, al mismo tiempo, brindar a los desarrolladores un acceso perfecto a herramientas protegidas desde el cliente MCP.
Si bien este ejemplo se centra en el servidor MCP de GitHub, el repositorio de código incluye ejemplos de integración para otros servidores MCP de terceros populares y una guía para alojar su propio servidor MCP con soporte de flujo de código de autorización en AgentCore Runtime como destino de AgentCore Gateway. Le animamos a explorar estos ejemplos y adaptarlos al panorama del servidor MCP de su organización.
Recursos
Para obtener más información, consulte los siguientes recursos:
Sobre los autores
Arko Dutta
Arko Dutta es ingeniero de software en Amazon Web Services y actualmente trabaja en el equipo de AgentCore Gateway. Durante su tiempo en Amazon, ha contribuido en varias organizaciones, incluidas Alexa Skills, Seller Flex y API Gateway, antes de unirse al equipo de Bedrock AgentCore Gateway. Fuera del trabajo, le gusta hacer senderismo y viajar.
Eashan Kaushik
Eashan Kaushik es arquitecto de soluciones especializado en IA/ML en Amazon Web Services. Su motivación es la creación de soluciones de inteligencia artificial generativa de vanguardia y, al mismo tiempo, prioriza un enfoque de su trabajo centrado en el cliente. Antes de ocupar este cargo, obtuvo una maestría en Ciencias de la Computación de la Escuela de Ingeniería Tandon de la Universidad de Nueva York. Fuera del trabajo, le gustan los deportes, levantar pesas y correr maratones.
Sheetal Mohite
Sheetal Mohite es ingeniero de software en Amazon Web Services y forma parte del equipo de AgentCore Gateway. A lo largo de su mandato en Amazon, ha trabajado en múltiples organizaciones, incluida Consumer Robotics, y ahora contribuye a la construcción de una infraestructura escalable para sistemas de IA agente. Fuera del trabajo, le gusta el CrossFit, las carreras ocasionales y el senderismo.
Tanuja Joshi
Tanuja Joshi es ingeniera de software en Amazon Web Services y forma parte del equipo de AgentCore Gateway. Desde el comienzo de su mandato, ha estado trabajando en el espacio de IA agente, contribuyendo a servicios como Bedrock Agents. Cuando no está en el trabajo, le gusta leer y escalar rocas.