En los flujos de trabajo de desarrollo modernos, los desarrolladores dependen cada vez más de asistentes de codificación agentes como Kiro Integrated Development Environment (IDE) para interactuar con herramientas y servicios remotos. Sin embargo, las organizaciones requieren mecanismos de autenticación sólidos para proporcionar un acceso seguro y con identidad verificada entre estos asistentes de codificación agente y los servidores del protocolo de contexto modelo (MCP) empresarial.
Amazon Bedrock AgentCore es un servicio totalmente administrado que lo ayuda a implementar, administrar y escalar agentes de IA en producción. Uno de sus componentes clave, AgentCore Gateway, proporciona un punto de entrada centralizado para enrutar y proteger las comunicaciones entre el agente y la herramienta. Cuando un asistente de IA realiza una solicitud a un servidor MCP a través del Gateway, esa solicitud debe verificarse antes de procesarse. Esto se conoce como autenticación entrante. Solo los usuarios y agentes autorizados pueden acceder a las herramientas y servicios expuestos por el servidor MCP. Las organizaciones suelen gestionar las identidades de los usuarios a través de un proveedor de identidad (IdP), como Okta, Microsoft Entra ID o Amazon Cognito, que autentica a los usuarios y emite tokens de seguridad que verifican quiénes son.
Esta publicación demuestra cómo implementar el flujo de código de autorización abierta (OAuth) como mecanismo de autorización entrante para servidores MCP alojados en Amazon Bedrock AgentCore Gateway. Al final de esta guía, tendrá una configuración lista para producción en la que cada solicitud de asistente de IA se autentica con un token de identidad de usuario válido emitido por el proveedor de identidad de su organización.
lo que aprenderás
Cómo funciona el flujo de código de autenticación con AgentCore Gateway como servidor de recursos MCP. Configuración paso a paso del proveedor de identidad de su organización. Configuración de autenticación entrante de AgentCore Gateway. Integración con clientes Kiro IDE.
Descripción general de la solución
En una configuración de OAuth de flujo de código de autorización entrante, AgentCore Gateway actúa como un servidor de recursos MCP que requiere un token de identidad válido antes de permitir que los clientes AI accedan a cualquier herramienta.
El siguiente diagrama muestra la arquitectura de un extremo a otro para el flujo de código de autorización con AgentCore Gateway, incluidas las interacciones del proveedor de identidad, el cliente AI y el servidor MCP.
Figura 1: Diagrama de arquitectura de flujo de código de autorización.
Componentes clave
La solución implica que los siguientes componentes trabajen juntos para completar el flujo de autenticación:
Proveedor de identidad (IdP): gestiona la autenticación de usuarios y emite tokens. El diagrama anterior hace referencia a Amazon Cognito, pero puede ser el IdP de su organización. Usuario: el usuario final que se autentica con el IdP y cuya identidad se verifica para cada solicitud. Amazon Bedrock AgentCore Gateway: actúa como servidor de recursos OAuth, validando tokens y enviando solicitudes a servidores MCP. Asistente de codificación agente: Kiro IDE, que actúa como cliente OAuth y gestiona el flujo de autenticación. Servidor MCP: sus herramientas y servicios backend a los que el asistente de IA necesita acceder. Proxy MCP OAuth (opcional): ayuda a cerrar la brecha de estandarización de especificaciones entre asistentes de codificación agente, IdP y servidores MCP. Un proxy MCP OAuth ofrece una estandarización que admite el flujo del código de autorización.
El flujo del código de autorización entrante
Este flujo garantiza que cada solicitud que el asistente de IA envía al servidor MCP se autentique con un token de identidad válido que pertenece al usuario.
Conexión de cliente MCP: el asistente de codificación agente (por ejemplo, Kiro IDE) inicia una conexión al punto final MCP de AgentCore Gateway. Desafío de autenticación: la puerta de enlace detecta que la solicitud carece de un token válido y responde con un HTTP 401, incluido un encabezado www-authenticate que apunta al punto final de metadatos de recursos protegidos OAuth de la puerta de enlace (.well-known/oauth-protected-resource). Esto sigue el patrón de metadatos de recursos protegidos (PRM) de la especificación MCP. Descubrimiento: el cliente MCP obtiene los metadatos de recursos protegidos de la puerta de enlace, que devuelve la URL de descubrimiento del servidor de autorización del IdP (por ejemplo, https://{yourIdPDomain}/oauth2/default/.well-known/openid-configuration). Redirección de usuario: el cliente MCP abre el navegador del sistema del usuario y redirige al punto final de autorización del IdP con un desafío PKCE, solicitando los alcances configurados (por ejemplo, correo electrónico de perfil openid offline_access). Autenticación y consentimiento del usuario: el usuario ingresa sus credenciales en la página de inicio de sesión del IdP. El IdP verifica la identidad del usuario y solicita su consentimiento para autorizar la aplicación. Concesión de código de autorización: después de la aprobación, el IdP redirige el navegador del usuario a la URL de devolución de llamada local del cliente (administrada por el oyente local del cliente) con un código de autorización. Solicitud de intercambio de token: el cliente MCP envía el código de autorización junto con el verificador del código PKCE al punto final del token del IdP. Emisión de token: el IdP valida el código de autorización y el verificador PKCE, luego devuelve un token de acceso (y opcionalmente un token de actualización) al cliente MCP. Solicitud y validación de MCP autenticadas: el cliente MCP incluye el token de acceso en el encabezado de Autorización para todas las solicitudes posteriores. La puerta de enlace valida la firma, el vencimiento, el emisor y la audiencia o las reclamaciones personalizadas del token y luego envía la solicitud al servidor MCP de destino para su ejecución.
Figura 2: Secuencia de solicitud de flujo de código de autorización.
Descripción general de la configuración
La siguiente tabla resume la configuración requerida para cada componente en la configuración del flujo de código de autorización. Las instrucciones detalladas paso a paso se encuentran en la sección Implementación técnica.
Componente Configuración requerida 1 Proveedor de identidad Cree una aplicación web OpenID Connect (OIDC) con las concesiones de código de autorización y token de actualización habilitadas. 2 AgentCore Gateway Establezca la autorización de entrada en JWT. Configure la URL de descubrimiento para el emisor de su IdP (por ejemplo, https://{yourIdPDomain}/oauth2/default/.well-known/openid-configuration). 3 Kiro IDE Agregue la URL de la puerta de enlace en Configuración > Conectores (o mediante la CLI). El cliente activa automáticamente el flujo de OAuth si la puerta de enlace devuelve un 401 no autorizado con los encabezados de autenticación correctos.
Implementación técnica
Con la arquitectura y el flujo establecidos, configure cada componente. Esta sección proporciona instrucciones paso a paso para los tres componentes a los que se hace referencia en la tabla de descripción general de la configuración:
Proveedor de identidad: registre una aplicación OIDC y configure tipos de concesión, redireccione URI y configuraciones de token. AgentCore Gateway: habilite la autorización entrante basada en JWT y apúntela al punto final de descubrimiento de su IdP. Cliente MCP (Kiro IDE): conecte el cliente a la URL de la puerta de enlace y verifique el flujo OAuth de un extremo a otro.
Requisitos previos
Debe tener los siguientes requisitos previos para seguir adelante.
Una cuenta de AWS con AgentCore Gateway implementado. Un proveedor de identidad (IdP) con permisos para configurar una aplicación (por ejemplo, Amazon Cognito, Okta, Auth0 u otros proveedores de identidad empresarial). Proxy MCP OAuth. Kiro IDE instalado localmente. Comprensión básica de los flujos de OAuth 2.0.
Paso 1: configurar el proveedor de identidad de la organización
En este paso, registra una aplicación OIDC con el proveedor de identidad de su organización y la configura para admitir el flujo de código de autorización con PKCE.
1.1 Crear una aplicación OIDC
Inicie sesión en la consola de administración de su IdP y cree una nueva integración de aplicación OIDC/OAuth 2.0:
Método de inicio de sesión: OIDC. Tipo de aplicación: Aplicación web. Nombre: cliente AgentCore Gateway (o su nombre preferido).
1.2 Configurar tipos de concesión
Habilite los siguientes tipos de concesión:
Código de autorización. Actualizar token.
1.3 Establecer URI de redireccionamiento
Agregue la URL de devolución de llamada que utilizará su cliente de IA:
http://localhost:PUERTO/devolución de llamada
Reemplace PORT con el puerto que utiliza su cliente.
1.4 Configurar los ajustes del token
En la configuración de su aplicación IdP, haga lo siguiente.
Duración de los tokens:
Vida útil del token de acceso: 1 hora (recomendado). Duración del token de actualización: 90 días (ajuste según sus requisitos de seguridad). Vida útil del token de identificación: 1 hora.
1.5 Tenga en cuenta su configuración
Guarde los siguientes valores. Los necesitará para la configuración de la puerta de enlace:
ID de cliente: se encuentra en la pestaña General de la aplicación (necesario para la configuración del cliente Kiro IDE). URL del emisor: la URL del emisor de su IdP (por ejemplo, https://{yourIdPDomain}/oauth2/default). URL de descubrimiento: el punto final de descubrimiento de OpenID Connect de su IdP (por ejemplo, https://{yourIdPDomain}/oauth2/default/.well-known/openid-configuration).
Para esta configuración:
No se requiere secreto de cliente: este flujo utiliza PKCE (Clave de prueba para intercambio de código), que está diseñado para clientes públicos como aplicaciones de escritorio. Kiro IDE no necesita ni utiliza el secreto del cliente. No hay puntos finales de IdP en la configuración del cliente: Kiro IDE descubre los puntos finales de OAuth automáticamente desde la puerta de enlace, que devuelve la URL de descubrimiento. No configura las URL de IdP directamente en el cliente.
Paso 2: Configurar la puerta de enlace AgentCore
Con su proveedor de identidad configurado, el siguiente paso es conectar AgentCore Gateway a su IdP para que pueda validar los tokens entrantes.
2.1 Establecer el modo de autorización entrante
Configure su puerta de enlace para utilizar la autenticación basada en JWT con el punto final de descubrimiento de su IdP:
2.2 Validación de reclamo personalizado
AgentCore Gateway valida tokens JWT basados en notificaciones estándar de OAuth 2.0 y admite la validación de notificaciones personalizadas para adaptarse a diferentes implementaciones de IdP. El Gateway espera que los tokens contengan:
Reclamaciones estándar: iss (emisor), aud (audiencia), exp (vencimiento), iat (emitido en), client_id (identidad del cliente) y alcances (ámbitos permitidos). Identificación del cliente: el Gateway puede validar la identidad del cliente a través de varios reclamos dependiendo de su IdP.
Otros IdP pueden usar nombres de notificaciones diferentes para la identificación del cliente, ámbitos, etc. (por ejemplo, cid, azp, scp). Puede configurar una validación de reclamo personalizada en su Gateway para que coincida con la estructura de token de su IdP:
Reclamo personalizado: IGUAL (consulte AgentCore Gateway: configurar un JWT). Ejemplo: cid IGUAL A 0oaz7147z771FZmdQ697 (para IdP que usan cid, como Okta). Esto valida que el token se emitió para su aplicación específica.
Nota: El campo Audiencia permitida de la puerta de enlace se puede mantener vacío cuando se utiliza la validación de reclamo personalizada. La verificación de reclamo personalizada proporciona la verificación de identidad del cliente necesaria.
2.3 Comprender la validación del token de puerta de enlace
Ahora que la puerta de enlace está configurada con la URL de descubrimiento y las reglas de reclamo de su IdP, observe cómo valida los tokens entrantes en tiempo de ejecución.
AgentCore Gateway está diseñado para ser independiente de cómo el usuario obtuvo el token de OAuth. Gateway no distingue entre tokens adquiridos a través de lo siguiente:
Flujo de credenciales del cliente, donde la aplicación se autentica directamente. Flujo de código de autorización, donde el usuario se autentica y otorga consentimiento explícitamente.
La puerta de enlace solo requiere que el token de OAuth presentado en la solicitud sea válido según los parámetros configurados durante la configuración de la puerta de enlace:
Firma del token: verificada con las claves públicas de la URL de descubrimiento del IdP. Caducidad del token: valida que el token no haya caducado. Emisor (reclamo de iss): coincide con el emisor de IdP esperado. Audiencia o reclamos personalizados: valida que el token se emitió para esta puerta de enlace o aplicación específica. Reclamaciones estándar de OAuth: comprueba las reclamaciones requeridas como iat, exp, etc.
Ya sea que los usuarios obtengan tokens a través de un flujo de credenciales de cliente, un flujo de código de autorización u otro tipo de concesión de OAuth, Gateway trata todos los tokens por igual. Siempre que el token pase las comprobaciones de validación configuradas en la configuración de su puerta de enlace, la solicitud está autorizada. Con esta flexibilidad, puede elegir el flujo de autenticación que se ajuste a su caso de uso y, al mismo tiempo, mantener una seguridad constante en el nivel de puerta de enlace.
2.4 Verificar la configuración de la puerta de enlace
Pruebe que su punto final de Gateway sea accesible y requiera autenticación:
La siguiente respuesta confirma que la autenticación está configurada correctamente (una respuesta 401 a solicitudes de MCP no autenticadas):
# Respuesta esperada que muestra que se requiere autenticación: HTTP/2 401 www-authenticate: Bearer Resource_metadata="https:///.well-known/oauth-protected-resource" {"jsonrpc":"2.0","id":0,"error":{"code":-32001,"message":"Missing Bearer token"}}
Paso 3: proxy MCP OAuth
A los efectos de esta publicación, utilice mcp-remote para estandarizar la interfaz del cliente MCP y completar el flujo del código de autorización.
3.1 Instalar el paquete mcp-remote
Utilice mcp-remote para conectar el cliente MCP de Kiro IDE con el punto final protegido por OAuth de la puerta de enlace.
Nota: mcp-remote es una prueba de concepto funcional y debe considerarse experimental.
Paso 4: configurar el cliente AI (Kiro IDE)
Con el proxy Gateway y MCP OAuth configurados, el paso final de configuración es conectar su cliente AI al punto final de Gateway. Kiro IDE maneja el flujo de OAuth automáticamente. Cuando recibe un desafío 401 del Gateway, inicia el flujo del código de autorización con su IdP.
4.1 Configurar Kiro IDE
Agregue la puerta de enlace a su archivo de configuración de MCP en ~/.kiro/settings/mcp.json:
Parámetros de configuración:
Comando: utilice mcp-remote para conectarse a servidores MCP remotos (mcp-remote). Primer argumento: la URL de su puerta de enlace con la ruta /mcp. Segundo argumento: puerto local para la devolución de llamada de OAuth (por ejemplo, 3334). –static-oauth-client-info: cadena JSON que contiene: client_id: su ID de cliente de la aplicación IdP. redirigir_uris: debe coincidir con el puerto especificado en el segundo argumento. alcance: incluya el correo electrónico de perfil openid offline_access para la autenticación básica.
4.2 Probar el flujo de autenticación
Después de agregar la conexión de puerta de enlace, verifique que el flujo de autenticación se complete correctamente:
Reinicie su cliente de IA. Intente utilizar una herramienta del Gateway. Serás redirigido a tu navegador para iniciar sesión con tu IdP. Después de una autenticación exitosa, la herramienta se ejecuta.
Paso 5: verificar el flujo de un extremo a otro
Una vez que todos los componentes estén configurados y la autenticación inicial sea exitosa, verifique que el flujo completo funcione de un extremo a otro, desde que el cliente de IA envía una solicitud de herramienta, pasando por la validación del token en la puerta de enlace, hasta recibir una respuesta del servidor MCP.
5.1 Validación del token de verificación
Supervise los registros de su puerta de enlace para confirmar la validación del token:
# Ejemplo de entrada de registro que muestra una validación exitosa [INFO] Token validado exitosamente para el usuario: usuario@ejemplo.com [INFO] Herramienta de ejecución: list_files
Para obtener un tutorial paso a paso sobre el uso de Okta como IdP, consulte este repositorio de GitHub.
Limpiar
Si siguió esta publicación y desea deshacer los recursos que creó, complete los siguientes pasos. Se presentan en orden inverso al de creación, de modo que los recursos dependientes se eliminan antes que los componentes de los que dependen.
Revocar tokens de OAuth
Antes de eliminar cualquier configuración, revoque cualquier token activo emitido durante la prueba. Consulte la documentación de su IdP para conocer la URL exacta del punto final de revocación y los parámetros admitidos.
Consideraciones clave que varían según el IdP:
URL del punto final de revocación: consulte el documento de descubrimiento de OpenID Connect de su IdP (el campo revocation_endpoint). Tipos de token aceptados: algunos IdP solo aceptan tokens de actualización. Otros aceptan tokens de acceso y de actualización. Autenticación del cliente: los clientes públicos suelen pasar client_id en el cuerpo. Los clientes confidenciales pueden requerir un encabezado de Autorización básica con credenciales codificadas. Comportamiento en cascada: revocar un token de actualización generalmente invalida sus tokens de acceso asociados, pero confirme con su IdP.
También puede borrar los tokens almacenados en caché local eliminando el caché de autenticación remota de mcp. En macOS o Linux:
Eliminar la configuración del cliente AI (Kiro IDE)
Elimine la entrada Gateway de su configuración Kiro IDE MCP en ~/.kiro/settings/mcp.json. Elimine el bloque del servidor gateway-tools que agregó en el Paso 4.
Eliminar el proxy MCP OAuth
Desinstale el paquete mcp-remote que instaló en el Paso 3:
Eliminar la configuración de AgentCore Gateway
Elimine la configuración de autenticación entrante que configuró en el Paso 2 o elimine la puerta de enlace por completo si la creó únicamente para este tutorial:
Opción A: eliminar la autenticación entrante (conservar la puerta de enlace)
Opción B: eliminar la puerta de enlace
Eliminar la configuración del proveedor de identidad de la organización
Elimine la integración de la aplicación OIDC que creó en el Paso 1:
Inicie sesión en la consola de administración de su IdP. Vaya a Aplicaciones > Aplicaciones. Seleccione la aplicación que creó (por ejemplo, “cliente AgentCore Gateway”). Primero desactive la aplicación (si su IdP lo requiere) y luego elimínela.
Esto revoca todas las credenciales del cliente y evita cualquier emisión futura de tokens para esta aplicación.
Conclusión
En esta publicación, aprendió cómo implementar un acceso seguro con identidad verificada a servidores MCP alojados en Amazon Bedrock AgentCore Gateway mediante el flujo de código de autorización entrante. Con esta configuración, cada solicitud de asistente de IA se autentica con un token de usuario válido del proveedor de identidad de su organización.
Conclusiones clave
El flujo de código de autorización proporciona una autenticación sólida al requerir el consentimiento del usuario y la verificación de identidad. AgentCore Gateway actúa como un servidor de recursos OAuth, validando tokens antes de permitir que las solicitudes invoquen objetivos. El flujo es transparente para los usuarios finales. Se autentican una vez y los tokens se actualizan automáticamente. Esta arquitectura se escala para admitir múltiples clientes de IA y proveedores de identidad.
Recursos adicionales
Sobre los autores
Swagat Kulkarni
Swagat es arquitecto senior de soluciones en AWS y un practicante activo de IA generativa. Trabaja con líderes ejecutivos y tecnológicos en transformación empresarial, estrategia en la nube e ingeniería de IA, incluida la adopción de IA generativa y agente. Con una sólida experiencia en impulsar la transformación digital en diversas industrias, Swagat ha brindado soluciones impactantes que permiten la innovación y la escala. Fuera del trabajo, le gusta viajar, leer y cocinar.
Anagh Agrawal
Anagh es ingeniero de software en Amazon Bedrock AgentCore, donde crea una infraestructura de puerta de enlace central que impulsa experiencias de IA agente. Anteriormente trabajó en Amazon Bedrock Agents y aporta la experiencia en sistemas distribuidos y servicios criptográficos de su tiempo en AWS Key Management Service. Tiene una maestría en Ciencias de la Computación de la Universidad Stony Brook. Fuera del trabajo, Anagh es un músico que toca el piano y el ukelele, y un ávido excursionista al que le encanta todo lo que esté al aire libre.
Navneet Sabbineni
Navneet trabaja como director de desarrollo de software en AgentCore. Él y su equipo trabajan actualmente en la creación de sistemas que ayuden a los clientes a realizar la transición de la prueba de concepto (POC) a la producción. Anteriormente trabajó como ingeniero senior en la mejora de las capacidades conversacionales de los chatbots impulsados por Amazon Lex. Cuando no está en el trabajo, le gusta explorar el aire libre.
Daniel Suárez Souto
Daniel es Arquitecto de Soluciones en Amazon Web Services, especializado en Inteligencia Artificial. Ayuda a los clientes a acelerar la adopción de la IA y a crear sistemas de IA seguros y escalables de extremo a extremo, convirtiendo los casos extremos del mundo real en patrones reutilizables que ayudan a los clientes a moverse más rápido. En su tiempo libre, a Daniel le gusta jugar fútbol, correr y hacer senderismo.