DevGENT
テクノロジー

MCP都度同意をOBOと認可サーバー4要件で切る判断基準

テクノロジーの観点で、MCPツールごとの都度同意をOBOとRFC 8693のトークン交換で減らし、読者が使える…

krona23
33〜50分

エージェントが MCP や社内 API を増やすたびにブラウザの同意画面へ戻す設計は、エージェントに Cookie が無い時点で破綻します。テクノロジーの現場で起きている「認可疲れ」の本体は、画面の多さではなく、ブラウザ SSO をエージェントに期待していることです。

📑目次
  1. テクノロジー運用で都度同意が止まる理由はブラウザSSOが使えないこと
  2. OBOはRFC 8693のトークン交換で宛先だけを付け替える
  3. ベンダーOBOの制約を先に潰す
  4. ID-JAGはIdP経由の代替でありまだDraft
  5. 認可サーバーが満たす要件と本番前チェックリスト
  6. よくある質問
  7. まとめ

最初の IdP 認証で得た inbound トークンを、宛先ごとの短命トークンへ交換してください。これが On-Behalf-Of（OBO）の実務です。RFC 8693 のトークン交換、各ベンダーの OBO 制約、まだ Draft の ID-JAG を並べ、実装前に切る判断基準を具体値付きで整理します。

読者の次アクションは次です。自社フローを impersonation か subject-plus-actor 委任かに切り、認可サーバーが次の 4 要件をその場で満たすかを点検してください。

  1. RFC 8693 token-exchange、または RFC 7523 jwt-bearer を受け付ける
  2. inbound JWT の署名 / iss / aud / exp を検証する
  3. (iss, sub) からユーザーと権限を解決する
  4. aud が API / MCP の access token を発行する

問題は「認可画面が多い」こと自体ではありません。エージェントが Cookie を持てないのに、ブラウザと同じ SSO 体験を期待していることです。

典型フローは 3 段です。

  1. IdP でユーザーを認証し、inbound トークンを受領する
  2. ツール / MCP ごとに認可を取りに行く
  3. 取得したトークンでツールを実行する

止まるのは 2 です。ブラウザならセッション Cookie が横断します。エージェントランタイムにはその Cookie がありません。

数値と制約は次のとおりです。

  • 典型的な id_token の expires_in は約 3599 秒（約 1 時間）です
  • aud が自分を含まないトークンは受け入れ拒否です（OIDC Core §3.1.3.7）
  • ログイン証明の sub はメールアドレスではなく、IdP 内の一意 ID です。Entra では横断識別に oid + tid を使います

impersonationを避ける

やってはいけないのは、ユーザーのセッションや広い範囲の Bearer トークンを MCP へそのまま横流しする impersonation です。

  • Codebasing（2026-08-10） は、この再利用が監査をユーザー本人の操作に潰し、権限集合を丸ごと露出すると述べています
  • Strivacity も、ログインで得たトークンは認証証拠であり、各 MCP 操作への版付き同意ではない、と切ります

MCP を増やすほど同意画面が増える、という見え方の裏には、この設計ギャップがあります。ツール接続の選択そのものは、MCP vs CLI の比較 で別軸として整理できます。ここでは認可ホップだけを扱います。

OBOはRFC 8693のトークン交換で宛先だけを付け替える

OBO は「同じユーザー証明を別 API に使い回す」ことではありません。/token へ POST し、audience を付け替えた access token を新しく発行させることです。

手順は次です。

  1. 最初のログインで得た id_token（または inbound access token）を subject_token にする
  2. grant_type=urn:ietf:params:oauth:grant-type:token-exchange とクライアント認証を付け、外部サービスの token endpoint へ POST する（リダイレクトなし）
  3. 応答の access token を MCP / API の Authorization: Bearer <exchanged_access_token> に使う
POST /oauth/token HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:token-exchange
&subject_token=<inbound_id_token>
&subject_token_type=urn:ietf:params:oauth:token-type:id_token
&audience=https://mcp.example.com
&scope=mcp.execute

交換後クレームの読み方

  • iss はサービス側認可サーバーへ変わります
  • aud は MCP / API へ移動します
  • sub はユーザーを指し続けますが、発行者が変わると値はサービス名前空間へ変わります。仕様は値の維持を要求しません
  • act.sub が代行したエージェント / クライアントです

寿命と subject / actor

RFC 8693 の発行例は expires_in: 3600 です。交換後トークンは短命（例: 600 秒）に落とすのが実務側の推奨です。

Arcjet の agentic identity 解説 は、安全な委任の条件を次のように述べます。

  • ユーザートークンだけでは「どのエージェントが動いたか」が消える
  • ワークロード ID だけではユーザー同意が無い
  • subject と actor の両方を残す
  • audience ごとに downscope する
  • 委任チェーンの伸びを抑える
  • 重大操作の直前に再認可する

NHIMG（2026-08-14） は、この交換をエージェント委任の制御面として扱い、信頼境界ごとに actor / subject / audience-bound scope を要求するよう IAM チームへ書いています。

ベンダーOBOの制約を先に潰す

「OBO 対応」と書かれていても、grant の形や禁止事項はプロトコルによって異なります。実装前にその違いを表にまとめて固定しておいてください。ここが技術選定における重要な分岐点です。

方式 grant / フラグ 主体 使えない条件 出典
RFC 8693 交換 urn:ietf:params:oauth:grant-type:token-exchange subject + 任意 actor 認可サーバーが未対応なら不可 IETF RFC 8693
Entra OBO jwt-bearer + requested_token_use=on_behalf_of ユーザー principal のみ アプリ専用トークン、wildcard reply の id_token、カスタム署名鍵の中間 API Microsoft Learn
Agent 365 OBO Entra OBO を実行モードとして定義 ユーザー=subject、エージェント=actor Blueprint 権限は管理者同意が別途必要 Microsoft Learn 2026-08-14
AgentCore OBO ON_BEHALF_OF_TOKEN_EXCHANGE 呼び出し元 + エージェント IdP が TOKEN_EXCHANGE か JWT_AUTHORIZATION_GRANT か要設定 AWS Docs
Traefik MCP Gateway RFC 8693 で Token B を発行 同じ sub / 権限、新しい aud Gateway はヘッダ転送のみ。交換実装は MCP サーバー側 Traefik Hub docs

出典

出典は次です（2026年8月時点）。

Entraの追加制限

Entra ID の追加制限は、実務では意外と踏みやすい落とし穴になっています。

  • 中間層トークンを別 audience へリレーしない
  • Roles はユーザーに残り、アプリへ付け替えない
  • SPA は confidential な中間層へ access token を渡す
  • アプリ専用トークンに OBO は使えません

実行モードと管理者同意

Microsoft Agent 365（更新 2026-08-14）は、OBO を実行モードとして定義します。ユーザーが subject、エージェント identity が actor です。

S2S（ユーザー文脈なし）や Agentic-User（エージェント自身のユーザーアカウント）とは明確に異なる仕組みです。Blueprint で宣言した権限であっても、管理者同意は別途必要になります。

交換フラグと actor オプション

Amazon Bedrock AgentCore は、ランタイム API GetResourceOauth2Token に oauth2Flow=ON_BEHALF_OF_TOKEN_EXCHANGE を付けます。

  • grant は TOKEN_EXCHANGE（RFC 8693）か JWT_AUTHORIZATION_GRANT（RFC 7523）です
  • actor オプションは NONE / M2M（client credentials + 任意 actorTokenScopes） / AWS_IAM_ID_TOKEN_JWT（outbound web identity federation が前提）です
  • 最終の grant / scope 判断は認可サーバー側です

ユーザーRBACかの検証

検証例もあります。Headwaters（2026-08-09） は、Entra OBO で Azure AI Search を呼ぶ実装を示します。

ユーザーの data-plane ロールを外すと HTTP 403 になり、共有アプリキーではなくユーザー RBAC に縛られていることが分かります。

Gatewayはヘッダ転送だけ

Gateway に交換を期待しないでください。Traefik Hub は、Gateway が Authorization ヘッダを転送または削除するだけだと書いています。Token B の発行は MCP サーバーと IdP の仕事です。

ID-JAGはIdP経由の代替でありまだDraft

会社全体で「このエージェントをこの外部サービスへ出してよいか」を IdP で決めたいなら、見る先は ID-JAG です。ただし今すぐ全 IdP で使える標準ではありません。

2 ホップです。

  1. IdP へ RFC 8693 で ID-JAG Assertion を取る（aud = 外部認可サーバー）
  2. 外部認可サーバーへ RFC 7523 jwt-bearer で提示し、access token を取る

制約は明確です。

  • draft-ietf-oauth-identity-assertion-authz-grant-04（更新 2026-05-21、Expires 2026-11-22、WG Document）
  • IdP が ID-JAG を発行できること、外部 AS が jwt-bearer を受けること、仕様が未確定な箇所があること
  • ドラフト例の access token は expires_in: 86400、scope 例は agent.read agent.write

企業向けの言い換え

企業向けの言い換えが Enterprise-Managed Authorization です。NHIMG は、per-connector 同意画面を IdP のポリシー判定へ移す、と整理しています。

短命・sender-constrained（DPoP / cnf）と task-scoped RAR が推奨です。対話型の OBO と、エージェント自身が subject になる自律実行は別物として扱ってください。

社内エージェント基盤の権限モデルを別角度で見るなら、Cloudflare OS の Gatekeeper 型ゼロトラスト も隣接テーマです。こちらは ambient MCP 直結を避ける実装例です。

認可サーバーが満たす要件と本番前チェックリスト

SSO を既に持っていても、OBO は「grant 受付」と「MCP 向けトークン発行」が新規になります。ここを埋めないと都度同意は消えません。テクノロジー判断は、画面 UX ではなく token endpoint の能力で行ってください。

認可サーバーの 4 要件です。5 は任意です。

  1. RFC 8693 token-exchange、または RFC 7523 の ID-JAG / jwt-bearer を受け付ける
  2. inbound JWT を検証する（署名 / iss / aud / exp）。OIDC SSO なら JWKS 検証を流用しやすいです。SAML SSO なら JWT 検証が追加になります
  3. (iss, sub) からサービス内ユーザーと権限を解決する
  4. aud = API / MCP の access token を発行する
  5. （任意）要求 scope を落とす

読者チェックリストです。

  • impersonation（ユーザートークン再利用）を拒否し、task-scoped 交換にする
  • トークンに subject と actor の両方を残す
  • audience を MCP と backend で分ける
  • 交換は MCP サーバー（または専用 broker）が行い、gateway は転送だけに限定する
  • 重大操作の直前に再認可する（有効な委任 ≠ 今の意図）
  • 失効と委任チェーンの監査ログを残す
  • IdP 未対応なら ID-JAG を前提にしない

委任トークンが広く残り続けると、ツール側の注入被害がユーザー権限ごと広がります。MCP 経由の乗っ取り面は Agentjacking の事例整理 も参照してください。認可設計と攻撃面は別記事ですが、広い Bearer の横流しは両方を悪化させます。

よくある質問

Q1. 最初のログインさえ済めば、すべての MCP を無同意で呼べますか？

いいえ。交換先の認可サーバーが grant を受け、そのユーザーに該当 scope がある場合だけです。未同意の権限は発行されません。

Q2. ユーザーの access token を MCP に渡せば早くなりませんか？

早く見えて危険です。監査がユーザー本人に潰れ、権限集合が丸ごと露出します。audience 付きの短命トークンへ交換してください。

Q3. Entra を使っているなら RFC 8693 は不要ですか？

Entra OBO は jwt-bearer + requested_token_use=on_behalf_of です。RFC 8693 そのものではありません。IdP の文書どおりの grant を選んでください。

Q4. ID-JAG を今すぐ本番の既定にできますか？

いいえ。2026-05-21 更新の WG Draft で、Expires は 2026-11-22 です。IdP と外部 AS の双方対応を確認してからにしてください。

Q5. Gateway がトークン交換までやってくれますか？

Traefik Hub の文書では、Gateway は Authorization ヘッダの転送または削除だけです。交換は MCP サーバーと IdP の仕事です。

関連記事:

まとめ

都度同意は、エージェントにブラウザ SSO を求めている設計バグに近いです。

直近の実装は、RFC 8693（またはベンダー OBO）で subject と actor を残した短命トークンへ交換することです。ID-JAG は IdP 集中管理向きですが Draft です。未対応 IdP を前提にしないでください。

次の一手は、自社フローを impersonation か subject-plus-actor 委任かに切り、認可サーバーが次の 4 要件をその場で満たすかを点検することです。

  1. RFC 8693 token-exchange または RFC 7523 jwt-bearer を受け付ける
  2. inbound JWT の署名 / iss / aud / exp を検証する
  3. (iss, sub) からユーザーと権限を解決する
  4. aud が API / MCP の access token を発行する

判断材料は同意画面の少なさではなく、audience 分離と監査可能性です。

📖 この記事で紹介した関連記事

krona23

著者

krona23

IT業界20年以上の実務経験を持ち、日本国内有数のPVを誇る大規模Webサービスで事業部長・CTOを複数社で歴任。Windows/iOS/Android/Webと技術の変遷を経験し、現在はAIネイティブへの変革に注力。DevGENTでは、AIコードエディタ・自動化ツール・LLMの実践的な使い方を日英西3言語で発信中。

DevGENT について →

📚 次に読む

← 前の記事ChatGPTとCodexの使い分け｜チャットとGitHub作業を委任する方法【2026】次の記事 →Claude Code Hooksとは？AIルールを強制する設定方法【2026】

🔥 よく読まれている記事

  1. Obsidian 視覚化の選び方｜Graph Canvas 比較
  2. Kimi K3の導入判断｜料金・ベンチ・API注意点
  3. Gemini 3.7 Flashの価格・性能を比較｜3.6との違いとAPI採用判断
  4. AI人生相談の助言を実行する前に｜依存・誤判断を防ぐ確認手順
  5. iPhone Duo出荷予測の比較と判断手順

コメントを残す

Trending

DevGENTをもっと見る

今すぐ購読し、続きを読んで、すべてのアーカイブにアクセスしましょう。

続きを読む