Управляемое согласие пользователя: в Amazon Bedrock AgentCore появился Consent portal для OAuth-доступа агентов

Что приходилось строить самим

Агентам часто нужен доступ к сервисам вроде GitHub и Slack от имени пользователя, и до того, как агент начнёт действовать, человек должен авторизоваться у провайдера и явно одобрить запрошенный доступ, а приложение — безопасно связать выданное OAuth-разрешение с тем, кто его выдал. Этот шаг называется session binding, то есть привязка сессии.

Раньше заказчикам, использовавшим трёхсторонний OAuth-поток (3LO, он же OAuth 2.0 authorization code flow) в AgentCore Identity, приходилось самостоятельно создавать и хостить инфраструктуру привязки сессии: показывать пользователю authorization URL, поднимать публичный HTTPS-callback, аутентифицировать возвращающегося пользователя, управлять браузерными сессиями и вызывать CompleteResourceTokenAuth для завершения потока.

Что появилось теперь

AgentCore Identity получил Consent portal — управляемый веб-опыт и endpoint привязки сессии для AgentCore Gateway. Портал создаётся для конкретного gateway, а его URL раздаётся пользователям: человек аутентифицируется через корпоративный identity provider (IdP), видит, какие сервисы доступны агенту, и выдаёт согласие по каждому провайдеру отдельно.

Браузерные редиректы и привязку сессии портал берёт на себя, а полученные токены AgentCore Identity складывает в свой token vault. Особенно это полезно для агентов, к которым обращаются из IDE и клиентов Model Context Protocol (MCP) — Kiro, Claude Code, Cursor и Visual Studio Code: пользователь выдаёт согласие до вызова инструмента, а последующие вызовы используют уже сохранённый для него токен.

Сценарий: ассистент разработчика с доступом к GitHub

В разборе AWS приводит компанию Example Corp, которая выдаёт разработчикам AI-ассистента через AgentCore Gateway: у ассистента два target — GitHub, умеющий показывать репозитории и создавать issue, и Slack, умеющий читать публичные каналы и публиковать сообщения. Аутентификация сотрудников идёт через корпоративный IdP, а администратор хочет, чтобы каждое OAuth-разрешение GitHub и Slack оставалось привязано к тому сотруднику, который его одобрил, и чтобы разработчики могли подключать провайдеров независимо друг от друга и возвращаться в IDE без повторных запросов.

Администратор настраивает IdP, target'ы GitHub и Slack, execution role и сам портал, после чего отправляет разработчикам ссылку; конечный пользователь открывает её, входит через корпоративный IdP, подключает GitHub, а Slack при необходимости выдаёт согласие отдельно. Проверкой служит простая деталь: после возврата в портал GitHub показан подключённым, а Slack — нет, что и демонстрирует независимость согласий.

Что нужно на стороне администратора

Помимо аккаунта AWS с доступом к Amazon Bedrock AgentCore требуются AgentCore Gateway с inbound-авторизацией по JWT, IDE или MCP-клиент, подключённый к тому же gateway, административный доступ к корпоративному IdP, зарегистрированные приложения GitHub OAuth App и Slack, а также право прописать callback URL AgentCore Identity в каждом из этих приложений.

В IdP создаётся OIDC-приложение с authorization code grant и как минимум scope openid, а IdP должен выдавать access token в виде JWT, который портал сможет проверить — например, в Okta для этого нужен отдельный authorization server с access policy, а в Auth0 — настроенный audience, иначе вместо подписанного JWT вернётся opaque-токен.

Для политики IAM перечислены действия CreateConsentPortal, GetConsentPortal, ListConsentPortals и работа с OAuth-провайдерами и target'ами gateway; при выборе опции создания роли по умолчанию консоль создаёт сервисную роль с именем AmazonBedrockAgentCoreConsentPortalDefaultServiceRole с суффиксом. Один Consent portal допускается на gateway, а сам gateway после создания изменить нельзя; имя портала принимает от 1 до 50 символов, описание — до 512. Когда provisioning завершается, статус меняется на Active и появляется URL вида https://<gateway-name>.consent-portal.bedrock-agentcore.<region>.amazonaws.com.

Отдельно нужно развести callback'и: адрес <portal-url>/callback прописывается в приложении корпоративного IdP и возвращает пользователя после входа в портал, <portal-url>/connect/callback указывается как default return URL для каждого 3LO-таргета gateway и возвращает пользователя к управляемому endpoint привязки сессии, а собственный callbackUrl AgentCore Identity регистрируется в приложении самого провайдера, чтобы тот передал код авторизации в AgentCore Identity.

Как это работает под капотом

Портал проверяет ответ IdP и поднимает зашифрованную браузерную сессию, после чего через свою execution role получает список 3LO-таргетов привязанного gateway. Когда пользователь нажимает Connect, портал вызывает GetResourceOauth2Token и получает authorization URL и session URI; провайдер возвращает код авторизации в AgentCore Identity, браузер попадает на управляемый endpoint привязки сессии, и портал вызывает CompleteResourceTokenAuth уже с контекстом аутентифицированного пользователя.

Если провайдер возвращает refresh-токен, AgentCore Identity сохраняет его и дальше сам получает новый access token после истечения текущего. Когда валидного refresh-токена нет — провайдер его не выдал, токен истёк или отозван — пользователю придётся вернуться в портал и авторизоваться заново, поэтому провайдера стоит настраивать на выдачу refresh-токенов, например включив истечение user-to-server токенов для GitHub или ротацию токенов для Slack. При следующем открытии портала подключённые провайдеры остаются видимыми, а повторное согласие требуется только после отзыва или истечения разрешения; подключение можно и разорвать кнопкой Disconnect.

Аудит в CloudTrail и уборка ресурсов

Amazon Bedrock AgentCore пишет операции согласия в AWS CloudTrail: в истории событий фильтр по event source bedrock-agentcore.amazonaws.com показывает GetResourceOauth2Token в момент старта OAuth-авторизации, CompleteResourceTokenAuth в момент завершения привязки сессии и GetWorkloadAccessTokenForJWT, когда портал получает доступ к gateway для аутентифицированного пользователя.

Событие GetResourceOauth2Token содержит credential provider, запрошенные scopes, тип OAuth-потока, execution role портала и регион, а чувствительные значения токенов и состояния скрыты; для разбора сбоев в AWS советуют сопоставлять errorCode и errorMessage со временем события, использованной ролью, регионом, провайдером и запрошенными scopes.

Когда ресурсы больше не нужны, удаляют портал, убирают его callback URL из приложения IdP и из target'ов gateway, а затем удаляют target'ы, outbound-провайдеров, провайдера корпоративного IdP и execution role портала; важно соблюсти порядок — сначала target, потом его outbound credential provider, поскольку провайдер, на который ещё ссылается target, удалить нельзя.