AWS showed how to connect OAuth-protected MCP servers to Bedrock AgentCore Gateway

AWS показала, как подключать защищённые OAuth MCP-серверы к Amazon Bedrock AgentCore Gateway через Authorization Code flow. Сценарий рассчитан на команды, которым нужен единый вход для AI-агентов в корпоративные инструменты без вшитых токенов и ручной настройки каждой интеграции.

Зачем нужен

Gateway Amazon Bedrock AgentCore Gateway AWS позиционирует как центральную точку, через которую агенты и MCP-клиенты получают доступ к инструментам внутри компании. Вместо того чтобы настраивать каждый MCP-сервер отдельно в IDE, команда может дать разработчикам один URL Gateway и единые правила доступа. В этот слой AWS выносит аутентификацию, наблюдаемость и контроль политик доступа, чтобы подключения к инструментам не разрастались в набор разрозненных ручных конфигураций.

Это особенно актуально для компаний, где MCP-серверов становится много: собственные внутренние сервисы, GitHub, Salesforce, Databricks и другие внешние системы. Многие такие серверы защищены OAuth 2.0 и требуют, чтобы агент действовал от имени конкретного пользователя.

В такой схеме Gateway снимает с приложений лишнюю работу: не нужно встраивать креды в код, самостоятельно обновлять токены или повторять одну и ту же логику для каждого коннектора.

Два режима подключения В статье AWS показывает два способа подключить OAuth-защищённый MCP-сервер к

Gateway. Первый — implicit sync при создании target: администратор проходит Authorization Code flow на этапе CreateGatewayTarget, UpdateGatewayTarget или SynchronizeGatewayTargets, после чего Gateway сам считывает список инструментов и кэширует его. Второй — передать схему инструментов заранее, не дожидаясь живого запроса к серверу во время создания target. AWS прямо называет второй вариант предпочтительным там, где участие человека в create или update невозможно.

• Implicit sync требует, чтобы админ завершил авторизацию и дал Gateway доступ к MCP-серверу ещё на этапе настройки.
• Pre-defined schema позволяет сразу вставить список tools и получить готовый target без авторизации при создании.
• В режиме со схемой заранее нельзя использовать SynchronizeGatewayTargets, потому что Gateway опирается на переданное описание, а не на живое чтение сервера.
• Пользователи Gateway могут делать tools/list без логина в каждый сервер, потому что определения инструментов уже лежат в кэше.
• Авторизация запускается только тогда, когда пользователь реально вызывает нужный инструмент через tools/call. В качестве примера AWS использует MCP-сервер GitHub. Для такого сценария нужен Gateway на версии MCP 2025-11-25 или новее, иначе опция Authorization code grant 3LO будет недоступна. В конфигурации также указывается return URL: именно туда пользователь или администратор возвращается после consent-экрана, а затем приложение завершает обмен через CompleteResourceTokenAuth.

Как проходит авторизация Ключевая часть схемы — связка AgentCore Gateway и AgentCore Identity.

Сначала Gateway получает workload access token, подтверждая, что он вправе запрашивать учётные данные от имени своей нагрузки. Затем через credential provider он либо получает готовый access token, либо URL авторизации и session URI, если для конкретного пользователя токен ещё не выпущен. На этапе первичной настройки target из-за этого может оказаться в статусе Needs authorization, а после завершения согласия перейти в Ready с пометкой Authorized.

AWS отдельно акцентирует URL session binding. Механизм проверяет, что авторизацию начал и завершил один и тот же пользователь, а не тот, кто случайно получил пересланную ссылку. После consent браузер возвращается на callback, приложение передаёт session URI и идентичность пользователя в CompleteResourceTokenAuth, и только после этой проверки происходит обмен authorization code на access token.

По данным AWS, ссылка авторизации и session URI живут 10 минут, что дополнительно сужает окно для злоупотреблений. Для конечного пользователя логика выглядит проще. Запрос tools/list обслуживается из кэша Gateway и не заставляет логиниться во все подключённые системы заранее.

А вот tools/call уже инициирует Authorization Code flow только для того MCP-сервера, чей инструмент действительно вызывается. После успешного входа токен кэшируется в Token Vault в связке workload identity и user identity, поэтому повторные вызовы проходят без новой авторизации, пока токен остаётся действительным.

Что это значит AWS двигает MCP из набора точечных интеграций в управляемый корпоративный слой.

Для команд, которые строят агентные системы на нескольких внешних и внутренних инструментах, это снижает хаос в доступах: каталог tools можно показывать централизованно, а пользовательскую авторизацию включать только в момент реального вызова нужного сервера.