AWS Bedrock AgentCore Consent Portal：Agent 的 OAuth 不只是按下 Connect

AI agent 要代替使用者讀 GitHub issue、查 Slack 或操作其他 SaaS 時，真正困難的通常不是把 OAuth 按鈕畫出來，而是證明「這一位使用者、在這一個 agent session、對這一個 Gateway、授予了這一組 scope」。AWS Machine Learning Blog 在 2026-09-14 發布的 AgentCore Consent Portal walkthrough 把這段常被各團隊重造的流程交給 Amazon Bedrock AgentCore Identity 與 Gateway。

它的價值不在於多了一個 Connect page，而在於把 end-user consent、portal session binding、Gateway resource 與 outbound provider token custody 放進同一條可觀測流程。不過，這仍是一篇 AWS 的 reference walkthrough：文章展示「AWS 文件描述的 flow 如何串起來」，不是獨立 security review，也沒有替企業證明所有 IdP、scope、session、IAM 或 provider compatibility 都安全。

先看完整的責任鏈

圖：Bloss0m 工程化整理，將 AWS walkthrough 的 identity login、portal session binding、outbound provider consent、token lifecycle 與 CloudTrail evidence 分成不同邊界；這不是 AWS 官方原圖，也不代表已完成安全保證。

Consent Portal 的最小心智模型可以拆成五個角色：

角色	在流程中負責什麼	不應被誤認成什麼
End user	在瀏覽器完成 corporate IdP login，並針對 GitHub、Slack 等 target provider 個別 consent	不是一個可以把所有 provider scope 一次授予 agent 的超級帳號
Corporate IdP	證明使用者與組織身分，向 portal 回傳 OIDC／JWT result	不是 GitHub 或 Slack 的 outbound resource provider
AgentCore Gateway	暴露 agent 可呼叫的 tool／resource，承接 inbound JWT 與 target return flow	不是替每個 end user 保存所有第三方 refresh token 的應用程式
AgentCore Identity	管理 portal session binding、取得 workload access token，並完成 resource token exchange	不是讓任意 Gateway request 自動取得 provider scope 的授權器
Outbound provider	GitHub、Slack 或其他 OAuth app 的 consent、access token 與 refresh token issuer	不是 Consent Portal 的 primary corporate IdP

這個角色拆分很重要，因為企業常把「使用者登入 agent」和「使用者把 GitHub 權限交給 agent」想成同一個 OAuth。AWS 文件的語意是兩段不同的 delegation：先用 corporate IdP 確認 principal，再讓這位 principal 對某一個 outbound resource provider 做另一次 consent。若兩段 scope、subject、audience 或 callback 被混在一起，後續 CloudTrail 記錄也很難說明到底是哪一次授權產生了哪一顆 token。

三條 callback：最容易接錯的地方

AWS 的 Consent Portal configuration guide 與 prerequisites 對 callback 的角色有很清楚的區分。把它整理成 routing table：

Callback	誰呼叫	回到哪裡	它完成的事情
portal-url/callback	Corporate IdP 回傳	AgentCore Consent Portal	完成 portal 的 primary identity login 與 session binding
portal-url/connect/callback	Gateway target 或 default return flow	Consent Portal 的連線流程	把 Gateway request 導回使用者的 target connection experience
AgentCore Identity callbackUrl	GitHub、Slack 或其他 outbound OAuth app 回傳	AgentCore Identity 的 resource token exchange	讓 Identity 完成 provider token 綁定與後續 resource token 取得

這三條 URL 的 authority 不一樣。第一條不是 GitHub callback；第二條不是一般 OAuth provider 的 redirect URI；第三條也不是任意 application frontend 可以替換的 callback。實作時應把每一條 URL、client ID、secret、state、redirect URI、issuer、audience 與 token owner 寫入 configuration contract，並在部署後用實際 browser trace 與 CloudTrail event 逐一核對。

AWS 文件也提醒，Consent Portal 的 primary IdP 要是能提供 OIDC／JWT 的 issuer，且需要 openid scope。GitHub 與 Slack 在這個 walkthrough 中是 outbound resource providers，不應被寫成 primary corporate IdP。這不是說 GitHub 或 Slack 不能有自己的 OAuth flow，而是它們在這套 AgentCore architecture 裡扮演的角色不同。

Admin flow：先把 trust boundary 建好

管理員流程不是「建立一個 portal」而已。依 AWS walkthrough 與 supporting docs，部署前至少要完成以下順序：

1. 準備 corporate IdP：確認 issuer、discovery endpoint、client ID、client secret、redirect URI 與 openid scope。要先決定哪些 claim 用來辨識 tenant、user、group 與 policy context。
2. 準備 outbound provider app：在 GitHub、Slack 或其他 resource provider 設定 OAuth app、client credentials、allowed scopes 與 AgentCore Identity 的 callbackUrl。每個 provider 都要有自己的 scope review 與 revoke／re-consent policy。
3. 建立 Gateway inbound auth：Gateway 以 JWT inbound authorization 驗證呼叫者；不要把 inbound corporate identity 與 outbound provider token 當成同一個 credential。
4. 建立 Consent Portal：使用 AgentCore Identity 的 managed portal URL 與 Gateway relationship；AWS 文件描述每一個 Gateway 一個 portal 的配置邊界，不能假設一個全域 portal 可以自動替所有 Gateway 做 isolation。
5. 保存 secrets 與設 IAM role：client secret 等敏感設定放在 Secrets Manager，Gateway／Identity 使用最小 execution role；role 的 trust policy、resource policy、KMS 權限與 secret read 權限要一起審。
6. 註冊 redirect URL 與 allow-list：把 primary IdP callback、connect callback、outbound provider callback 分別登記；不要以 wildcard redirect URI 取代明確的 environment／tenant mapping。

這六步顯示 managed portal 解決的是 common plumbing，不是把 security responsibility 交給 AWS 產品名稱。當企業新增 provider、換 IdP、加 scope、開 multi-tenant Gateway 或改 callback domain，仍要重新檢查 principal、audience、token owner 與 audit events。

End-user flow：兩次同意，兩種 token

實際使用者的 flow 可以寫成一個狀態機：

1. 使用者從 agent 或 Gateway target 進入 Consent Portal。
2. Portal 將使用者導向 corporate IdP；使用者在 IdP 完成登入。
3. Portal 依 callback result 綁定登入 principal 與當前 portal session。
4. 使用者看到可連線的 resource provider，例如 GitHub 或 Slack，逐一點選 connect。
5. Provider 顯示自己的 OAuth consent page；使用者檢查 scope 後同意。
6. Provider 回傳到 AgentCore Identity 的 callbackUrl，Identity 完成 resource token authentication。
7. Gateway／agent 之後以 session-bound context 呼叫 GetResourceOauth2Token，或用 GetWorkloadAccessTokenForJWT 取得對應的 workload access token。
8. 若 provider 需要 refresh，Identity 依其 token lifecycle 保存與更新；若 refresh token 過期、scope 改變或使用者 revoke，流程回到 re-consent，而不是靜默擴張權限。

這裡要分清 access token 與 workload access token 的語意。前者代表某個 outbound provider 的 resource authorization；後者是 agent／workload 在 AgentCore boundary 內使用的 access path。即使兩者最後都長得像 bearer token，也不應在 log、cache 或 API contract 中互相替代。

AWS walkthrough 也包含 CompleteResourceTokenAuth 這類完成 token auth 的操作，以及 token 取得與 refresh 的注意事項。production implementation 不應只把 API call 串起來，還要保存 correlation ID、portal session、provider、user subject、scope hash、token expiry、refresh outcome 與 revoke reason。token 本體不能進 application log；若需要 debug，記 hash、metadata 與 event reference。

CloudTrail 與 session binding：可見不等於已證明

這套 flow 的一個好處是，AWS 文件把 session binding、token acquisition 與 identity operation 放入可以觀察的 CloudTrail／service event surface。企業可以用這些記錄回答：

• 哪一個 Gateway 觸發了 consent？
• corporate IdP 回傳的 principal 是誰、在哪個 tenant？
• 使用者授予哪一個 outbound provider、哪些 scope？
• token 取得是第一次 consent、refresh、re-consent，還是 error recovery？
• 哪一個 agent workload 使用了哪一個 session-bound token？
• 使用者 revoke 或 provider token failure 後，舊 session 是否被標記為不可用？

但「有 CloudTrail event」不能自動推出「session swap 不可能發生」或「token isolation 已通過獨立 audit」。AWS 文章沒有提供 CSRF、login CSRF、authorization-code interception、session fixation、tenant mix-up、callback confusion 或 token replay 的獨立測試結果。這些是企業在採用前應自行做的 security verification。

Scope 與 token custody：不要把 managed flow 當成 least privilege

Consent Portal 可以讓 end user 看見 provider consent page，但 scope review 仍是平台與產品責任。建議把 scope 分成三層：

Scope layer	例子	審核問題
Identity	openid、subject、tenant／group claims	這些 claim 是否只用於識別，還是被誤當成 resource authorization？
Resource read	讀 issue、讀 channel、讀 repository metadata	agent 是否真的需要全部 read scope？能否縮到 repository、channel 或 project？
Resource write	建立 issue、送訊息、改檔案、呼叫外部 action	是否需要 human approval、二次確認、write policy 與 rollback？

把 refresh token 交給 token vault 並不代表「風險被 AWS 自動消除」。仍要驗證誰能讀 vault、誰能呼叫 GetResourceOauth2Token、是否有 cross-tenant lookup、如何處理 cache、多久 revoke、provider 端 revoke 後多久失效，以及 debug／support workflow 是否會把 token material 帶出邊界。文件描述的是 service capability，不是企業環境的 independent isolation certificate。

更實際的設計是把 provider authorization 與 tool capability 分開。使用者可以同意讀 Slack，但 agent policy 仍只允許搜尋特定 channel；使用者可以同意 GitHub repository read，但 tool schema 仍禁止 write；若要開 write，policy event 要記錄誰、為何、何時、哪一條 approval rule 允許。

失敗模式：看似正常的 OAuth 也可能沒有完成授權

實作時最常遇到的 failure modes 不在 happy path：

• IdP callback 成功、provider consent 失敗：登入 principal 已存在，但 resource token 尚未建立；UI 不應顯示「GitHub 已連線」。
• provider callback 成功、session binding 不一致：如果 state、tenant、Gateway 或 browser session 對不上，應 fail closed，不要用最近一次 token 猜測使用者。
• refresh token 失效：讓 agent 進入 re-consent／reauthorization state；不要無限重試，也不要把 refresh error 轉成 generic 500 讓使用者無法修復。
• scope 變更：provider 要求新的 scope 時，視為新的 consent，而不是沿用舊 token 的成功狀態。
• Gateway 被複製到另一個 environment：callback、secret、execution role 與 tenant mapping 必須 environment-bound；避免 staging token 被 production workload 讀取。
• 使用者 revoke：要能從 provider revoke、AgentCore Identity state、Gateway session、cache 與 downstream audit 反查並停用。
• CloudTrail 不完整：event delivery delay、跨帳號查詢、retention 與 redaction 會影響 incident timeline；不能只假設 console 目前看得到就代表永久可查。

這些 failure modes 也解釋為什麼「managed callback」不是「不用設計 callback」。平台少寫了一些 web server code，卻多了一個需要精確配置的 identity／Gateway contract。

與 Bloss0m 既有文章的連結

如果你剛開始建立 Agent governance，可以先讀企業 AI Agent 的安全邊界總覽；它把 identity、tool、memory 與 human control 放在同一張架構圖裡。GitHub MCP enterprise controls 則適合拿來對照 resource scope、audit 與 write capability。Forge MCP Auth Runtime 會把 auth state 往 runtime policy 再推近一層；若你正在評估 AgentCore workflow，也可以接著讀AWS Step Functions × Bedrock AgentCore 的 validation boundary。

什麼是 AWS 文件明確說的，什麼還需要自己證明？

類別	AWS post／docs 明確提供的內容	企業不能直接從中推出的結論
Flow	managed portal、primary IdP、outbound provider、callback 與 token API 的 walkthrough	所有 OAuth provider／IdP 都相容
Identity	OIDC／JWT、openid scope、Gateway／Identity integration	tenant isolation、session swap 或 claim mapping 已通過獨立驗證
Token	token vault、GetResourceOauth2Token、CompleteResourceTokenAuth、workload access token	token 永不出現在 log、cache 或 support surface
Audit	CloudTrail／service event 可用於追蹤部分 operation	event 完整、即時、不可竄改，且足以重建每一次 downstream effect
Operations	prerequisite、execution role、Secrets Manager 與 cleanup 順序	availability、cost、latency、revocation SLA 或 production adoption

這個差異是本文的核心判斷。Vendor documentation 很適合用來建立 implementation checklist，但 security conclusion 需要另外的 threat model、penetration test、negative test、IAM review、multi-tenant test、provider compatibility matrix 與 incident drill。

原文出處與核對範圍

• AWS Machine Learning Blog：Manage end-user OAuth consent for AI agents with Amazon Bedrock AgentCore
• AgentCore Consent Portal configuration
• AgentCore Consent Portal prerequisites
• Amazon Bedrock AgentCore release notes

我以 2026-09-17 為核對日，閱讀 AWS 原文、Consent Portal configuration、prerequisites 與 release notes 的相關段落。這篇文章保留 AWS 的 product terminology 與流程描述，但將 security guarantee、token isolation、availability、成本與 compatibility 都列為尚未由這些 vendor sources 證明的項目。