All rights reserved by Postman Inc MCP認可の現在地と 自律型エージェント対応に向けた課題 川崎庸市 テクノロジーエバンジェリスト LT talk slides for Serverless Meetup Tokyo #21, 2025.08.06 

テクノロジーエバンジェリスト Postman株式会社 川崎 庸市 / Yoichi Kawasaki @postman_japan @yokawasa 

お話すること ● MCP認可 の現在地（20250618版時点） ● 自律型エージェント対応に向けたMCP認可の課題（頭出し） 

本当は30分位かけてお話ししたいところですが 5分という短い時間なので、各トピックの説明が雑になっ てしまうかもしれません。予め容赦ください🙏 

MCP認可の現在地 （20250618版時点） 

MCP認可の現在地 MCP認可は、20250618版までのアップデートにより、従来の手動設定や煩雑な事前準備を減らし、よ り安全で柔軟な認可フローを実現するための機能が強化された リソースと認可の責任分離 MCP仕様 20250326版では、MCPサーバーは、「リソースサーバー」と「認可サーバー」の両方の役割を担っていたが、 20250618版で、MCPサーバーは「リソースサーバー」として明確に定義され、認可の役割は認可サーバーが担当するようになっ た。→ ID管理の一元化、既存SSOとの連携など、エンタープライズ用途での利用が可能になってきた 自動検出と動的クライアント登録 MCPクライアントが、必要なエンドポイントを自動的に検出し、新しいサーバーに対して自らを動的に登録することができるようになっ た。ユーザーがクライアントIDや認可サーバーのエンドポイントといった情報を事前に手動で設定する必要がなくなった。自律的に動 作するAIエージェントが、MCPサーバーを自動的に検出し、自己登録・認可を行うようなユースケースを考えると、こうした機能は不 可欠と言える MCP認可 20250618 https://modelcontextprotocol.io/specification/20250618/basic/authorization 

MCP認可の自動検出と動的自己登録の動き https://qiita.com/yokawasa/items/74717789465ef2aeedfe MCP認可フローデモ Postman(MCPクライアント)で Notion MCPサーバにアクセス → 認可サーバーの自動検出 → 自己登録 → OAuthの認可フロー 最終的にアクセストークンを取得し、 Notion MCPサーバーにtool/list, tool/callリクエスト送信 

リソースと認可の責任分離 認可に必要な情報の自動検出と 動的自己クライアント登録 標準のOAuth認可 + PKCEProof Key for Code Exchange) フロー MCP認可フロー 20250618版) MCP サーバー 認可 サーバー 

主要な標準規格一覧 20250618版のMCP認可を構成する主要な標準規格: ● OAuth 2.1 認可フレームワーク (draft-ietf-oauth-v2113) ○ 認証コード保護のため認可サーバーはOAuth 2.1 PKCE必須) 実装必須。クライアントもPKCE実装必須 ● OAuth 2.0 保護リソースメタデータ (RFC9728) ○ MCPサーバーにリクエストし認可サーバーのURLなどの情報を取得するためのメタデータ ● OAuth 2.0 認可サーバーメタデータ (RFC8414) ○ 認可サーバーにリクエストし、認可・トークンエンドポイントなどの情報を自動取得するためのメタデータ ● OAuth 2.0 動的クライアント登録 (RFC7591) ○ クライアントは自動的に自己の詳細情報を認可サーバーに提供し、一意の識別子を受け取る。これにより自動クライ アント自己登録を実現 ● OAuth 2.0 リソースインジケーター (RFC 8707) ○ 不正なリソースサーバーでのアクセストークンの使用を防ぐためにの仕組み 参考 

MCP認可20250618版)のフォローアップ記事 MCP認可フローを仕様から読み解く（ 20250618版） https://qiita.com/yokawasa/items/74717789465ef2aeedfe 

自律型エージェント対応に向けた MCP認可の課題（頭出し） 

自律型エージェント対応となると ● 自律型エージェント対応とはユーザーインタラクションが存在しない世界のサポート ● つまり、マシン to マシンの認可手段が必要になる ● さらに、複数エージェントが連携するシナリオにおける認可の考慮も必要 認可 サーバー MCP サーバー アクセス トークン取得 リソース要求 AIエージェント エージェントA エージェントB エージェントC タスクの依頼 

マシンtoマシン シナリオの認可フローとその課題 ● 今のOAuth認可フローの中で、マシン to マシンへのアプローチとしてはクライアントシークレットを 利用する「クライアント資格情報」がある ● しかし、シークレットの管理にはセキュリティ上の課題がある クライアント資格情報 認可フロー 「認可リクエスト」「 認可グラント」のやり取りを省略してクライ アント ID/クライアントシークレットを「認可グラント」として「アク セストークン」を直接取得する。ユーザーのインタラクションが 不要になる。 API 提供者自身のサーバーアプリなど、信頼できるクライアン トであることが保証できる場合にのみ使用。 シークレットの長期保持と漏洩リスク 同一シークレットの長期保有は漏洩や攻撃者による悪用 リスクが高くなるため、シークレットの有効期限の短縮化 や自動ローテーションなどが求められる 認可 サーバー MCP サーバー アクセス トークン取得 リソース要求 クライアントIDと シークレット AIエージェント 

OAuthの認可タイプ @postman_japan 認可コード 「認可リクエスト」で認可サーバー経由でユーザーに権限委譲を 依頼。「認可グラント」としてクライアントは認可コードを受け取る。 「認可グラント」である認可コードを使ってクライアントは「アクセス トークン」を取得。 「アクセストークン取得」の通信に使うクライアントシークレットを秘 匿できるサーバーアプリで使う。 インプリシット OAuth 2.1で廃止) 認可コードの派生型で、「 認可グラント」のやり取りを省略して「ア クセストークン」を直接取得する。「アクセストークン」取得の通信 に使うシークレットを秘匿できないモバイルアプリやブラウザの JavaScriptアプリで使う。 ただし、攻撃者によるアクセストークンインジェクションのリスクが 大きいため OAuth 単体での使用は非推奨。 パスワード資格情報 OAuth 2.1で廃止) 「認可リクエスト」「認可グラント」のやり取りを省略してユーザーが 入力した ID/パスワードを「認可グラント」として「アクセストークン」 を直接取得する。レガシーな認証フローをサポートするだけのた めに定義されている。 レガシーなパスワード認証のリスクがそのまま存在するため、あら ゆる状況で使用しないことが望ましい。 クライアント資格情報 「認可リクエスト」「 認可グラント」のやり取りを省略してクライアン ト ID/クライアントシークレットを「認可グラント」として「アクセストー クン」を直接取得する。ユーザーのインタラクションが不要になる。 API 提供者自身のサーバーアプリなど、信頼できるクライアントで あることが保証できる場合にのみ使用。 ● 参考1 OAuth 2.0 全フローの図解と動画 https://qiita.com/TakahikoKawasaki/items/200951e5b5929f840a1f ● 参考2 The OAuth 2.1 Authorization Framework - Compatibility with OAuth 2.0 参考 OAuth2.0で利用できた「インプリシット」と「パスワード資格情報」認可タイプはOAuth2.1で廃止 

RFC 7523 JSON Web Token Profile for OAuth 2.0 Client Authentication and Authorization Grants 静的なクライアントID/シークレットではなく、署名付きJWT（JSON Web Token）を使って、認可サーバー に認証する方法を定義した標準仕様。マシンtoマシン認可シナリオで有望視されている RFC 7523 JSON Web Token JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants https://www.rfc-editor.org/rfc/rfc7523 参考 RFC 7523 JWTベースのクライアント認証) がマシンtoマシン認可シ ナリオで有望な理由 ● クライアントシークレット不要 ○ 毎回使い捨ての署名付きJWTで認証するため、漏洩リスクを軽減 ● リクエスト毎に新しい JWT を生成 ○ JWT は jti（JWTの一意識別子）や exp（有効期限）などのクレーム情報に より、一度使用されたトークンを再利用できない構造 ● アクセス履歴が追いやすい ○ JWTにはどのクライアントが、どのリソースにアクセスしたいかという情報 が含まれており、監査しやすくなる { "iss":"https://jwt-idp.example.com", "sub":"mailto:[email protected]", "aud":"https://jwt-rp.example.net", "nbf"1300815780, "exp"1300819380, "http://claims.example.com/member":true } JWTペイロード例 

他にもさまざまな課題がある ● マルチホップシナリオの認可 ○ あるタスクを複数エージェントが連携しながら実行するシナリオ（A会議調整 → B 関係者に通知） ○ あるユーザーXの依頼からのエージェントABの実行シナリオでは、ABのエージェント間通信が発生するが、Xか らのアクセストークンをABにそのまま受け渡すのは危険 ○ 既存のOAuth 2.0/2.1仕様では、1段階の委任（ユーザー→クライアント）には対応できるが、多段階の委任（ユーザー →エージェントABC）には不十分 ● 認可スコープと権限の設計 ○ 自律型エージェントは、ユーザーインタラクションなしに複数リソースへアクセスすることが考えられるため、スコープや アクセス権限の定義を誤ると、過剰な権限を与えることになる ○ 各エージェントへの権限を最低限抑えつつ（最小権限の原則）、柔軟かつ効率的に認可設定できる仕組が必要 ● トレーサビリティの確保 ○ 自律型エージェントが複数のタスクやリソースをまたがって行動したとしても、誰がいつ何をしたかが分かるトレーサビ リティの確保が必要。コンプライアンスや監査要件として必要 

RFC 8693 OAuth 2.0 Token Exchange 既存のトークンを別の新しいトークンと交換するための標準仕様。マルチホップな委任やマイクロサービス 間通信といった複雑な認可シナリオにおいて、有望視されているようです RFC 8693 OAuth 2.0 Token Exchange https://www.rfc-editor.org/rfc/rfc8693.html エージェント間通信における FC 8693の提案issue https://github.com/modelcontextprotocol/modelcontextprotocol/issues/214 ● 安全な権限委譲の仕組みが必要 ○ マルチホップなシナリオ（ユーザー→エージェントABC）において、アクセストークンをそのまま下流のエー ジェントに受け渡すのは危険 ● RFC 8693は主に以下の用途に対応 ○ Delegation（委任） ○ Impersonation（成り代わり） ○ トークンのフォーマット変換、スコープの再調整など 参考 

まとめ ● MCP認可は今後のサービス連携やAIエージェントの時代において、ますます重要性が増していく ● MCP仕様 20250618版により、従来のOAuth 2.0と比べ、より安全、柔軟な設定が可能で、手動設定 の手間も大幅に削減された ● しかし自律型エージェント対応に際してはまだまだ課題があり、それら対応に向けてさまざまな議論が進 められている ○ マシンtoマシンシナリオ ○ マルチホップシナリオ ● 自律型エージェント対応に向けた今後のMCP認可の動向に目が離せない 🔥 

ご清聴いただき、ありがとうございました。 @postman_japan