用 Amazon Bedrock AgentCore 的 Consent portal 搞定

直接说结论：如果你在用 Amazon Bedrock AgentCore 给 AI Agent 接 GitHub 或 Slack 之类的第三方服务，以前得自己写一套 session binding 基础设施（包括搞 HTTPS 回调、管浏览器 session、调 CompleteResourceTokenAuth 等），现在可以用 AgentCore Identity 自带的 Consent portal 托管了。简单说就是 AWS 提供一个授权页面，用户在那儿点同意，Token 直接存到 AgentCore Identity 的 token vault 里，省去了自己搭一套认证链路的麻烦。

这玩意儿对用 Cursor、Claude Code、Kiro 或者 VS Code 这类 MCP 客户端的开发者比较有用，因为用户可以在调用工具前先在网页端把权限给掉，后面调用就不用反复跳授权了。

我之前在琢磨怎么给一个开发助手配置 GitHub 和 Slack 权限，按 Example Corp 的那个场景来看，逻辑是这样的：

管理员怎么配置这个授权链路

首先得在 AWS 管理控制台里把基础环境跑通。管理员需要做这几件事：
1. 配置公司内部的身份提供商（IdP），确保员工能通过公司账号登录。
2. 在 AgentCore Gateway 里创建 GitHub 和 Slack 这两个 target。比如 GitHub target 用来列仓库和建 issue，Slack target 用来发消息和看频道。
3. 配置好相应的 IAM 执行角色。
4. 创建 Consent portal 并拿到一个 URL 丢给开发者。

终端用户是怎么操作的

对于我们开发者来说，流程变成了这样：

• 打开管理员发来的那个 Consent portal URL。
• 用公司 IdP 账号登录。
• 在页面里看到 Agent 申请访问的 GitHub 或 Slack 权限。
• 点击授权。

整个重定向和 session binding 过程全在后台跑，用户点完同意，Token 就直接进到 AgentCore Identity 的仓库里了。而且它是独立授权的，我想连 GitHub 就不连 Slack，互不干扰。

实际运行中的细节和排查

这种托管方案最核心的变动就是把「 session binding」给标准化了。以前如果自己写回调接口，最容易在用户返回认证结果时出现 session 丢失或者匹配不上用户 ID 的报错。现在走 Consent portal，它会自动处理浏览器重定向，并把 Token 与授权用户绑定。

如果你怀疑权限没生效或者想确认 Token 是否真的存进去了，可以直接去 AWS CloudTrail 里查活动日志。只要在 CloudTrail 里能看到对应的授权请求记录，就说明链路通了。

这种方案在 IDE 场景下很关键。因为 Cursor 或 VS Code 这种客户端没法直接处理复杂的 OAuth 3LO 流程（三腿 OAuth），必须跳到浏览器。如果每次调用 GitHub 接口都要弹窗让用户登录，体验极差。有了这个托管门户，用户一次性在浏览器里授权完，后续在 IDE 里的工具调用就是静默通过，效率高很多。