Connection-based OAuthから学ぶOAuth for AI Agents

OpenID BizDay #18 ~ AIdentity × Security CollabDay ( https://openid.connpass.com/event/376275/ ) における、セキュリティエンジニアの松井 遼太朗の登壇資料です。

Transcript

1. Connection-based OAuth から学ぶOAuth for AI Agents 2025/12/19　OpenID BizDay #18 ~ AIdentity × Security CollabDay　 GMO Flatt Security株式会社 プロフェッショナルサービス部 セキュリティエンジニア 松井遼太朗 @ryotaromosao
2. © 2025 GMO Flatt Security Inc. All Rights Reserved. 自己紹介 Matsui Ryotaro（@ryotaromosao） GMO Flatt Security(株) プロフェッショナルサービス部 セキュリティエンジニア > 東北大学大学院情報科学研究科修了後、GMO Flatt Security株式会社 に新卒入社。プロフェッショナルサービス部においてWebアプリケー ションやLLMアプリケーションの脆弱性診断・ペネトレーションテス トに従事。また最近ではクラウドセキュリティに関するリサーチや
 AI × セキュリティ勉強会の主催などの活動にも取り組んでいる。
3. 趣味は麻雀と自作キーボードのKeymap作成(?) © 2025 GMO Flatt Security Inc. All Rights Reserved. 自己紹介
4. はじめに Connection-based OAuth？
5. Connection-based OAuthとは AI Agents用のToolのTokenを管理 or Tool結果を返してくれるサービス （Connection-based OAuth as a Service）で使用されている独自OAuth https://blackhat.com/us-25/briefings/schedule/#back-to-the-future-hacking-and- securing-connection-based-oauth-architectures-in-agentic-ai-and-integration-platforms-44686 Connection-based OAuth as a Service Connection#3 Token 従来 Connection-based OAuth as a Service Tool結果 Token Manager Connection { Connection ID, Tool ID, Agent ID, User ID, OAuth Token } Connection ID | Token A C B C Connection#1 | Connection#2 | Connection#3 |
6. はじめに 例えば、ArcadeのようなMCPランタイムサービス（AI Agentsと外部ツールを簡単に連携してくれる） でConnection-based OAuthが使用されている 複数のAI Agentsが複数Toolsを触りたい時、その実装・管理が煩雑になる MCPランタイムサービスを用いると、そのSDKを叩くだけで簡単にツールと連携ができる https://www.arcade.dev/
7. stateからConnectionを 特定 Connection-based OAuthのフロー /AddConnection /callback?code= &state=state code ① Start OAuth Connection ID| Token Connection#1 | Connection ID| Token Connection#1 | Tool ID/User ID +API Key Connection ID = #1 OAuth URL=/authorize /token with code access token User Agent Token Manager Authorization Server Connectionに紐づけてstateを生成 /authorize?state=state /GetFile Connection ID = #1 + API Key /GetFile Agent Backend Resource Server
8. Connection-based OAuthのフロー ヤバそうな実装ありますよね
9. stateからConnectionを 特定 Connection-based OAuthのフロー /callback?code= &state=state code Connection ID| Token Connection#1 | Connection ID| Token Connection#1 | Tool ID/User ID +API Key ConnectionはAuthorization sessionのような 役割を果たす Connection ID = #1 OAuth URL=/authorize OAuthクライアント1 OAuthクライアント2 /token with code Token Manager Connectionに紐づけてstateを生成 Connection ID = #1 + API Key Agent Backend Resource Server OAuth クライアントの役割 が、 user sessionを 管理 す る Agent Backend と、 Connection ・ stateを 管 理 す る Token Managerに 分 けら れ て いる state が user sessionに紐づ い て 管理・検証され て いない た め、本来 のstateの役割を果た し て いない
10. 攻撃例 - Session Fixation stateからそれに紐づいた Connectionを特定 /authorize?state=state 被害者を認可 エンドポイントに誘導 slack.com/authorize.. /authorize?state=state /callback?code= &state=state code ① Start OAuth 攻撃者のAI Agentsが 操作可能なConnection 被害者権限の操作ができるToken . . . Connection ID| Token Connection#1 | Connection ID| Token Connection#1 | User Agent User Agent Agent Backend 攻撃者のセッションで開始 Token Manager Authorization Server ④/token with code ⑤access token Connectionに紐づ けてstateを 生成
11. 攻撃例 - Session Fixationの対策 被害者にOAuth URL を踏ませる slack.com/authorize.. /authorize?state=state /callback?code= &state= code state /post_callback?code= &state= code state Agent Backend Token Manager Authorization Server < > code, state user id + api key /post_callbackによってstateをuser sessionと 紐づけた状態で検証 User Agent User Agent stateから、Connectionに紐づいているuser idと
 リクエストで送られてきたuser idが一致している かを検証
12. AI Agentsに認可委譲するための課題 OAuth2.0/2.1では誰が（sub）、どのアプリケーションに（azp）、どんな権限（scope）を 与えるのかの3軸構成であったが AI Agents登場後は誰が（sub）、どのアプリケーションの（azp）、 どんな権限（scope）を与えるのか、の3軸+ 構成 どのAI Agents （???）に 1軸 Connection-based OAuthでは、 により<tool, user, agent>を管理 攻撃者のAI Agentsが 状態を作れた 独自実装のConnection 被害者のリソースを操作できる トークン自体にどのAI Agentsに対して発行したものなのかという情報がない トレーサビリティを 担保できない ため、AI Agentsへ の認可委譲のフローに脆弱性があった場合やAI Agentsが異常行動した場合に 権限を与える/与えたAI Agentsを識別する パラメータが必要
13. OAuthのフローにAI Agentsの識別 を組み込める？
14. OAuth 2.0 Extension: On-Behalf-Of User Authorization for AI Agents https://www.ietf.org/archive/id/draft-oauth-ai-agents-on-behalf-of-user-02.html
15. On-Behalf-Of User Authorization for AI Agents フロー User Agent Client Agent(Actor) Authorization Server Resource Server 代理実行の要求 Actor ID /authorize?state=state&requested_actor=requested_actor requested_actor （Actor ID） PKCE client_id、scopeなど /callback?code= &state= code state /token with code, actor_token AI Agentsの識別子(sub claim)が含まれている必要がある actor_to kenが有効かつ期限内であることを 検証 actor_tokenに含まれるsub claimが requested_actorと一致することを検証 ユーザー認証・同意（人間にActorIDを提示）
16. On-Behalf-Of User Authorization for AI Agents フロー User Agent Client Agent(Actor) Authorization Server Resource Server 代理実行の要求 Actor ID /authorize?state=state&requested_actor=requested_actor ユーザー認証・同意 requested_actor （Actor ID） PKCE client_id、scopeなど /callback?code= &state= code state /callback?code= &state= code state /token with code, actor_token AI Agentsの識別子(sub claim)が含まれている必要がある actor_to kenが有効かつ期限内であることを 検証 actor_tokenに含まれるsub claimが requested_actorと一致することを検証 access token { 
 "iss": "https://authorization-server.com/oauth2/token", 
 "aud": "resource_server", 
 "sub": "user-456", 
 "azp": "s6BhdRkqt3", 
 "scope": "read:email write:calendar", 
 "exp": 1746009896, 
 "iat": 1746006296, 
 "jti": "unique-token-id", 
 "aut": "APPLICATION_USER" 
 } "act": { 
 "sub": "actor-finance-v1" 
 }, 
 どのAI Agentesに認可委譲したのか が明確になっている
17. まとめ AI Agents登場後は誰が（sub）、どのアプリケーションの（azp）、 どんな権限（scope）を与えるのか、の3軸+ 構成 どのAI Agents （???）に 1軸 Connection-based OAuthでは、 により<tool, user, agent>を管理 攻撃者のAI Agentsが 状態を作れた 独自実装のConnection 被害者のリソースを操作できる トークン自体にどのAI Agentsに対して発行したものなのかという情報がない トレーサビリティを 担保できない ため、AI Agentsへ の認可委譲のフローに脆弱性があった場合やAI Agentsが異常行動した場合に OAuth拡張のdraftでは、 、 により、 requested_actor actor_tokenの検証 どのAI Agents（act） に対して認可委譲をしているのか明確になる
18. ありがとうございました！ 2025/12/19　OpenID BizDay #18 ~ AIdentity × Security CollabDay　 GMO Flatt Security株式会社 プロフェッショナルサービス部 セキュリティエンジニア 松井遼太朗 @ryotaromosao （麻雀と自作キーボードのお話もしましょう ）