AWS为AgentCore网关推出OAuth同意门户，用户可逐一授权GitHub、Slack
Amazon Bedrock AgentCore Identity新增托管式Consent portal，替企业托管第三方OAuth授权中的浏览器跳转与会话绑定，开发者通过一个URL分别连接各服务商。
AI解读：Amazon Bedrock AgentCore Identity现在提供一个叫Consent portal的托管网页，用来替企业处理终端用户的OAuth授权。在此之前，使用AgentCore Identity三腿OAuth（3LO，即OAuth 2.0授权码流程）的客户得自己搭建并托管会话绑定基础设施：展示授权URL、托管公开HTTPS回调、认证返回的用户、管理浏览器会话，最后调用CompleteResourceTokenAuth完成流程。
新门户把这些环节接了过去：管理员建好门户、把URL发给用户；用户用公司身份提供商（IdP）登录，查看代理可用的服务，并逐个服务商授权。门户负责浏览器跳转和会话绑定，AgentCore Identity把令牌存进token vault。
对使用者来说，变化在于授权是分服务商独立的。示例里开发者连上GitHub后，Slack仍显示未连接，需要时再单独授权；之后从IDE或MCP客户端调用工具时可以直接复用已存的令牌，不必反复弹窗。
局限也明确：如果服务商没有发放refresh token，或它已过期、被撤销，用户必须回到门户重新授权。门户每个网关只能建一个，创建后不能更换网关，名称会展示给终端用户。
Amazon Bedrock AgentCore Identity新增Consent portal，这是一个托管式网页体验和会话绑定端点，面向AgentCore Gateway。此前使用3LO（三腿OAuth，即OAuth 2.0授权码流程）的客户需要自建并托管会话绑定基础设施，包括展示授权URL、托管公开HTTPS回调、认证返回用户、管理浏览器会话以及调用CompleteResourceTokenAuth。
管理员为网关创建一个门户并分享URL；用户用组织IdP登录，查看代理可用的服务，并逐个服务商授予同意。门户处理浏览器重定向和会话绑定，AgentCore Identity将令牌存入token vault。
AWS表示该能力对通过IDE和Model Context Protocol（MCP）客户端访问代理的场景特别有用，例如Kiro、Claude Code、Cursor和Visual Studio Code。用户可以在调用工具前授权，后续工具调用复用已为该用户存储的令牌。
门户怎么连接IdP、网关与出站服务商
门户验证IdP响应并建立加密浏览器会话，随后用其IAM执行角色列出所附网关的3LO目标。用户选择Connect时，门户调用GetResourceOauth2Token，拿到授权URL和会话URI。服务商把授权码返回给AgentCore Identity后，浏览器回到门户的托管会话绑定端点，门户带着已认证的用户上下文调用CompleteResourceTokenAuth。
- 管理员需要准备：可访问Amazon Bedrock AgentCore的AWS账户、配置JWT入站授权的AgentCore Gateway、连接到同一网关的IDE或MCP客户端、企业IdP管理权限，以及已在开发或测试空间注册的GitHub OAuth App和Slack应用。
- 需要在各服务商应用中注册AgentCore Identity回调URL，并有权限这么做。
- 门户从OAuth2凭证提供方读取IdP的client ID和client secret；OIDC发现文档提供授权端点、令牌端点和签名密钥。
- IdP必须签发门户可验证的JWT访问令牌。AWS举例：Okta要用自定义授权服务器和允许该应用及授权码授予的访问策略；Auth0在需要时配置audience，以便返回签名JWT而不是不透明令牌。
管理员配置：从IdP到门户URL
管理员按步骤先准备企业IdP和网关连接，再创建IdP凭证提供方，确认GitHub与Slack的出站前置条件，最后创建Consent portal。门户名称接受1–50个字符，可用字母、数字、连字符和下划线；描述最长512个字符。每个网关只允许一个Consent portal，创建后不能更换网关。
创建时选择IdP凭证提供方，作用域至少保留openid，audience除非网关指定否则保持None。IAM权限可选“Create default role”让控制台创建服务角色，或选“Use another role”。状态从Creating变为Active后，控制台显示门户URL，形如https://<...>.consent-portal.bedrock-agentcore.<...>.amazonaws.com。
- 回调URL分三类和作用：IdP应用配/callback（用户从门户登录返回）；网关目标把默认返回URL设为/connect/callback（回到托管会话绑定端点）；AgentCore Identity的callbackUrl配在出站服务商应用上，用于把服务商授权码送回AgentCore Identity。
- 需确认GitHub和Slack应用已注册、client secret存于AWS Secrets Manager，且出站OAuth凭证提供方各自注册了匹配的回调URL。
- 网关目标使用授权码授予，只申请必需scope，状态为Ready；门户执行角色能读取出站凭证提供方引用的客户托管密钥。
- 门户URL不要加结尾斜杠。
终端用户体验与幕后流程
用户打开门户URL、选择Sign in，浏览器跳转到企业IdP完成认证。门户用执行角色检索网关配置的目标及连接状态。在Connections页面选择GitHub的Connect，在GitHub同意页查看scope并批准，返回门户后GitHub显示Connected，Slack仍为Not connected，说明各服务商授权相互独立。需要Slack时再单独连接、选工作空间、查看权限并批准。
之后用户回到使用同一网关的IDE或MCP客户端重试相应工具调用即可。再次打开门户时，已连接的服务商仍然可见；除非授权被撤销、过期或需要重新同意，不必再次批准。用户也可以选择Disconnect，之后再重新连接。
- 服务商返回refresh token时，AgentCore Identity会存储并在当前访问令牌过期后自动用它换取新令牌。
- 若没有有效refresh token（服务商未发放、已过期或被撤销），访问令牌失效后用户必须回门户重新授权。
- AWS建议在服务商支持时配置发放refresh token，例如为GitHub启用user-to-server令牌过期、为Slack启用令牌轮换。
在CloudTrail中查看同意操作
Amazon Bedrock AgentCore把同意操作记录到AWS CloudTrail。在事件历史中按事件源bedrock-agentcore.amazonaws.com过滤，可看到三类事件。
- GetResourceOauth2Token：门户开始为某服务商发起OAuth授权。该事件标识凭证提供方、请求的scope、OAuth流程、门户执行角色和区域；敏感令牌和state值会被隐去。
- CompleteResourceTokenAuth：会话绑定完成时记录。
- GetWorkloadAccessTokenForJWT：门户为已认证用户获取网关访问权限时记录。
- 排查失败可用errorCode和errorMessage，结合事件时间、assumed role、区域、凭证提供方和请求的scope定位原因。
清理顺序与前置限制
不再需要资源时，需依次删除Consent portal、从企业IdP应用和网关目标移除门户回调URL、删除引用出站凭证提供方的网关目标、删除不再使用的出站OAuth凭证提供方和企业IdP凭证提供方，最后删除门户执行角色（若没有其他资源使用）。AWS特别提醒：必须先删网关目标再删其出站凭证提供方，仍被目标引用的凭证提供方无法删除。
- 管理员IAM策略需覆盖创建/获取/列出Consent portal、创建/获取/列出OAuth2凭证提供方，以及获取/列出/创建/更新网关目标等操作。
- 若使用控制台“Create default role”，AWS会创建名为AmazonBedrockAgentCoreConsentPortalDefaultServiceRole-的服务角色；自带角色时把iam:PassRole限定到该角色ARN。
- AWS提供了使用Microsoft Entra ID和Okta的端到端GitHub示例，可在Amazon Bedrock AgentCore示例仓库查看。