OAuth/OpenID Connectで実現するMCPのセキュアなアクセス管理

『OpenID TechNight vol.22 ~ AI時代のID管理「AIdentity」勉強会』の資料になります。
https://openid.connpass.com/event/356397/

Transcript

1. © OpenID Foundation Japan © OpenID Foundation Japan OpenID TechNight vol.22 OAuth/OpenID Connectで実現する MCPのセキュアなアクセス管理 一般社団法人 OpenIDファウンデーション・ジャパン 理事・エバンジェリスト 倉林 雅 2025年6月20日
2. © OpenID Foundation Japan #OpenIDTechNight #AIdentity 倉林 雅（kura） OpenIDファウンデーション・ジャパン 理事・エバンジェリスト OpenID・OAuth・パスキー技術の 啓発・教育活動に携わり、 現在は某インターネット企業にて プロダクトマネージャーを担当。 X: @kura_lab 著書「パスキーのすべて」 絶賛発売中
3. © OpenID Foundation Japan #OpenIDTechNight #AIdentity アジェンダ 1. はじめに 2. MCPに適用するOAuthのプロトコル 3. MCPでOAuthを開始するための準備 ◦ Q1. Authorization Serverをどのように見つけるの？ ◦ Q2. Authorization Serverのエンドポイントを どのように見つけるの？ ◦ Q3. Clientをどのように登録するの？ 4. OAuthフローの攻撃対策 ◦ Q4. 攻撃者によるAccess Tokenの発行を どのように防ぐの？ 5. 漏洩リスク低減策 ◦ Q5. Access Tokenに付与した権限は コントロールできるの？ 6. Account Take Over対策 ◦ Q6. どのようにユーザー認証するの？ 7. まとめ 3
4. © OpenID Foundation Japan はじめに 4
5. © OpenID Foundation Japan #OpenIDTechNight #AIdentity MCPとは • Model Context Protocol（MCP）とは、LLMアプリケーションと外部データソースやツールとの 連携を目的としたAnthropic社によって標準中のオープンプロトコル。 • AI搭載IDEの構築、チャットインターフェースの拡張、カスタム AIワークフローの作成などに用い られる。 MCP Server MCP Client LLM applications that initiate connections Connectors within the host application Services that provide context and capabilities Tools MCP Protocol JSON-RPC 2.0 HTTP or stdio Host 5
6. © OpenID Foundation Japan #OpenIDTechNight #AIdentity MCPがOAuthを必要とする理由 • MCP Serverやツールはホストマシンに閉じることもできる。 • MCP Serverを公開することによって多数のMCP Clientと接続でき、 外部データリソースやツールの利活用が進む利点がある。 • MCP Serverが多数存在することが想定されるため動的な登録と利用が求められる。 MCP Server MCP Client LLM applications that initiate connections Connectors within the host application Services that provide context and capabilities External data sources and Tools MCP Protocol JSON-RPC 2.0 HTTP or stdio Host External network 6
7. © OpenID Foundation Japan #OpenIDTechNight #AIdentity MCPがOAuthを必要とする理由 • MCP Serverを外部ネットワークに公開するユースケースは一般的なOAuthが適用される。 • 多段のOAuthをサポートすることでMCP Serverの外部データリソース接続も安全になる。 • OAuthには動的な登録や利用に対応した拡張仕様が提供されている。 • 今回はMCPにおけるOAuthのアクセス管理について解説する。 MCP Server MCP Client LLM applications that initiate connections Connectors within the host application Services that provide context and capabilities External data sources and Tools MCP Protocol JSON-RPC 2.0 HTTP or stdio Host Attacker External network 7
8. © OpenID Foundation Japan #OpenIDTechNight #AIdentity 標準的なAuthorization Flow Protected MCP Server MCP Client Resource Owner MCP Authorization Server Access Token Resource Serverとしてホストされることも、 別のエンティティとしてホストされることもある Access Token ユーザー認証・同意（オプション） Resource Server Client 8
9. © OpenID Foundation Japan #OpenIDTechNight #AIdentity Third-Party Authorization Server Third-Party Authorization Flow MCP Server MCP Client Resource Owner Third-Party ユーザー認証・同意 Client Resource Server Client Client Third-Party Resource Server Third-Party Access Token Authorization Server Resource Server ユーザー認証・同意（オプション） この例ではMCP Authorization Serverがホストされている Authorization Server 9 Access Token
10. © OpenID Foundation Japan #OpenIDTechNight #AIdentity MCPにOAuthを適用するにあたってでてくる疑問 Q1 Q2 Q3 Authorization Serverをどのように見つけるの？ Authorization Serverのエンドポイントをどのように見つけるの？ Clientをどのように登録するの？ Q4 Q5 攻撃者によるAccess Tokenの発行をどのように防ぐの？ Access Tokenに付与した権限はコントロールできるの？ Q6 どのようにユーザー認証するの？ MCPで提供されている最新・策定中の仕様を解説しながら疑問に回答する。 10
11. © OpenID Foundation Japan MCPに適用するOAuthのプロトコル 11
12. © OpenID Foundation Japan #OpenIDTechNight #AIdentity 認可を準拠すべきプロトコル MCPの実装において認可（Authorization）はオプションであるが、HTTPベースの場合には後述する OAuthの仕様に準拠すべきである。 プロトコル 要件 HTTPベースのトランスポート この仕様に準拠するべき (SHOULD) STDIOトランスポート この仕様に従うべきでない (SHOULD NOT) 代わりに、環境からクレデンシャル（認証情報）を取得するこ と その他の代替トランスポート そのプロトコルに対して確立されたセキュリティの ベストプラクティスに従わなければならない (MUST) 12
13. © OpenID Foundation Japan #OpenIDTechNight #AIdentity 準拠すべき標準仕様 • MCPではOAuth 2.1とOAuth 2.0の拡張仕様（Profile）が採用されている。 • 現在策定中のdraftではProtected Resource MetadataとResource Indicatorsが追加されている。 標準仕様 Latest（2025-03-26） draft OAuth 2.1 IETF DRAFT (draft-ietf-oauth-v2-1-12) ✅ ✅ OAuth 2.0 Authorization Server Metadata (RFC8414) ✅ ✅ OAuth 2.0 Dynamic Client Registration Protocol (RFC7591) ✅ ✅ OAuth 2.0 Protected Resource Metadata (RFC9728) ✅ Resource Indicators for OAuth 2.0 (RFC 8707) ✅ 13
14. © OpenID Foundation Japan #OpenIDTechNight #AIdentity 準拠すべき標準仕様 • MCPではOAuth 2.1とOAuth 2.0の拡張仕様（Profile）が採用されている。 • 現在策定中のdraftではProtected Resource MetadataとResource Indicatorsが追加されている。 標準仕様 Latest（2025-03-26） draft OAuth 2.1 IETF DRAFT (draft-ietf-oauth-v2-1-12) ✅ ✅ OAuth 2.0 Authorization Server Metadata (RFC8414) ✅ ✅ OAuth 2.0 Dynamic Client Registration Protocol (RFC7591) ✅ ✅ OAuth 2.0 Protected Resource Metadata (RFC9728) ✅ Resource Indicators for OAuth 2.0 (RFC 8707) ✅ Draftとなっているが、OAuth 2.0を現状のユースケースに合わせて セキュリティ強化されている仕様であるため、 これから適用するならばOAuth 2.1にすべきである。 14
15. © OpenID Foundation Japan #OpenIDTechNight #AIdentity OAuth 2.0とOAuth 2.1の差分 1/2 特徴/側面 OAuth 2.0 OAuth 2.1 根拠/セキュリティ上の利点 PKCE (Proof Key for Code Exchange) Public Client（モバイル アプリなど）にオプションで推 奨 すべての Clientに必須 Authorization Code横取り攻撃を防止し、 すべてのClient Typeでベースラインセキュ リティを向上 Implicit Grant Public Client向けにAccess TokenをURLフラグメントに直 接返すことを許可 削除され、非推奨 URLフラグメントからのToken漏洩（ブラウ ザー履歴、リファラー、XSS）の脆弱性を排 除 PKCEを伴うAuthorizationフローが 推奨される代替手段 Resource Owner Password Credential Grant (ROPC) ユーザー名とパスワードを Clientが直接収集し、Token と交換することを許可 削除され、非推奨 Clientによるクレデンシャル処理の リスクを排除 MFA/SSOの適用を容易にし、認証の 責任を認証サーバーに集中させる 15
16. © OpenID Foundation Japan #OpenIDTechNight #AIdentity OAuth 2.0とOAuth 2.1の差分 2/2 特徴/側面 OAuth 2.0 OAuth 2.1 根拠/セキュリティ上の利点 Redirect URI Matching ワイルドカードや部分文字列 パターンなど、 柔軟なマッチングを許可 厳密な文字列完全 一致が必須 オープンリダイレクターの脆弱性を 防止攻撃者がTokenを傍受したり、 アプリケーションになりすましたり するのを困難にする URIクエリパラメー ターにおける Access Token 明示的に禁止されていないた め、一部で採用される 可能性があった 禁止 ブラウザー履歴、サーバーログ、 リファラーヘッダーを介した Token 漏洩のリスクを排除 Authorizationヘッダーの使用を強制 Refresh Tokenセ キュリティ 使用に関する要件は厳しくな い ワンタイムユース/ ローテーションまたは 送信者制限が必須 （特にPublic Client向 け） Refresh Tokenが盗難または漏洩した場 合の損害を制限 リプレイ攻撃を防ぎ、Tokenの寿命を最小 限に抑える 16
17. © OpenID Foundation Japan #OpenIDTechNight #AIdentity MCPの各ロールに適用するプロトコル要件 Protected MCP Server （Resource Server） MCP Client （Client） Resource Owner MCP Authorization Server Access Token Access Token ユーザー認証・同意（オプション） OAuth 2.1 Dynamic Client Registration (RFC7591) Authorization Server Metadata (RFC8414) Protected Resource Metadata (RFC9728) Dynamic Client Registration (RFC7591) Protected Resource Metadata (RFC9728) Authorization Server Metadata (RFC8414) MUST SHOULD Resource Indicators for OAuth 2.0 (RFC 8707) 17
18. © OpenID Foundation Japan MCPでOAuthを開始するための準備 18
19. © OpenID Foundation Japan Q1 Authorization Serverをどのように見つけるの？ 19
20. © OpenID Foundation Japan ClientはMCP Serverにアクセスするための Access Tokenを発行する Authorization Serverを知らない 20
21. © OpenID Foundation Japan Clientから MCP Serverに Authorization Serverの 場所を尋ねる 21
22. © OpenID Foundation Japan #OpenIDTechNight #AIdentity Protected Resource MetadataでAuthorization Serverを見つける • まずClientはMCP ServerにアクセスするためのAccess Tokenを取得する必要がある。 • Authorization ServerのURLがわからないため、MCP ServerにAccess Tokenなしでリクエストする。 • MCP Serverは、OAuth 2.0 Protected Resource Metadata（RFC9728）に従い、Authorization ServerのURLおよ びサポートされている機能を返却する。 • これによりClientはAuthorization Serverを見つけることができる。 HTTP/1.1 200 OK Content-Type: application/json { "resource": "https://resource.example.com", "authorization_servers": ["https://api.example.com", "https://api.example.net"], "bearer_methods_supported": ["header"], "scopes_supported": ["profile", "email", "phone"] } HTTP/1.1 401 Unauthorized WWW-Authenticate: Bearer resource_metadata= "https://resource.example.com/.well-known/oauth-protected-resource" MCP Serverのエラーレスポンス Protected Resource Metadataレスポンス 401 Unauthorizedエラーとなるが WWW-Authenticateヘッダー上に Protected Resource MetadataのURLが返却される HTTP GETリクエスト Authorization ServerのURLが返却される 22 draft
23. © OpenID Foundation Japan Q2 Authorization Serverのエンドポイントを どのように見つけるの？ 23
24. © OpenID Foundation Japan Authorization Serverの場所はわかったが、 認可処理に必要なエンドポイントがわからないため Authorization Serverに尋ねる 24
25. © OpenID Foundation Japan #OpenIDTechNight #AIdentity Authorization Server MetadataでAuthorization Serverのエンドポイントを見つける • MCP ClientはAuthorization Serverと認可処理をするための各エンドポイントを知る必要がある。 • Authorization Serverは、OAuth 2.0 Authorization Server Metadata (RFC8414)に従い、Authorizationエンドポイ ントやTokenエンドポイントなどのURLを返却する。 • これによりMCP ClientはAuthorization Serverに対してAccess Tokenを取得するための認可処理ができる。 HTTP/1.1 200 OK Content-Type: application/json { "authorization_endpoint": "https://api.example.com/authorize", "token_endpoint": "https://api.example.com/token", "registration_endpoint": "https://api.example.com/register" } GET /.well-known/oauth-authorization-server HTTP/1.1 Host: api.example.com MCP Authorization Server Metadataリクエスト Protected Resource Metadataから抽出した ドメイン配下の.well-know HTTP GETリクエスト MCP Authorization Server Metadataレスポンス MCP Authorization Serverの 各エンドポイントの URLが取得できる 25 Latest draft
26. © OpenID Foundation Japan #OpenIDTechNight #AIdentity Authorization Serverのデフォルトエンドポイント Authorization Server Metadataを実装しない場合、 認可ベースURLを基準としたデフォルトのエンドポイントパスを使用しなければならない。 エンドポイント デフォルトパス 例 Authorizationエンドポイント /authorize https://api.example.com/authorize Tokenエンドポイント /token https://api.example.com/token Registrationエンドポイント /register https://api.example.com/register 26
27. © OpenID Foundation Japan Q3 Clientをどのように登録するの？ 27
28. © OpenID Foundation Japan Authorization Serverの場所や 認可処理に必要な各エンドポイントはわかったが、 Clientが登録されていないためOAuthを開始できない 28
29. © OpenID Foundation Japan この例では、MCP Serverが Authorization Serverとしても機能している Authorization ServerにClientを登録する 29
30. © OpenID Foundation Japan #OpenIDTechNight #AIdentity Dynamic Client RegistrationでClientを自動登録する • 新たなAuthorization Serverを使用するたびに、手動による Clientの事前登録はユーザーの手間となる。 • また、ClientがすべてのMCP ServerとAuthorization Serverを事前に把握しているとは限らない。 • そのため、Authorization ServerはOAuth 2.0 Dynamic Client Registration Protocol (RFC7591)に従い、Clientか らリクエストを受けて自動的に登録する。 HTTP/1.1 201 Created Content-Type: application/json Cache-Control: no-store Pragma: no-cache { "client_id": "s6BhdRkqt3", "client_secret": "cf136dc3c1fc93f31185e5885805d", "client_id_issued_at": 2893256800, "client_secret_expires_at": 2893276800, "redirect_uris": ["https://client.example.org/cb"], "grant_types": ["authorization_code", "refresh_token"], "client_name": "My Example MCP Client", "token_endpoint_auth_method": "client_secret_basic", } POST /register HTTP/1.1 Content-Type: application/json Accept: application/json Host: api.example.com { "redirect_uris": ["https://client.example.org/cb"], "client_name": "My Example MCP Client", "scope": "calendar contacts", "token_endpoint_auth_method": "client_secret_basic" } Client Registrationリクエスト Client Informationレスポンス OAuthに必要なClient ID/Secretが取得できる Clientの名称やscopeなどを登録する 30 Latest draft
31. © OpenID Foundation Japan #OpenIDTechNight #AIdentity ユーザーによるClientの手動登録機能の提供 Dynamic Client Registration ProtocolをサポートしないAuthrorization Serverは、 Client ID（Confidential Clientの場合はClient Credential）を取得するための代替手段を 提供する必要がある。 1. Authrorization Serverとの連携時に使用するClient ID（およびClient Credential）をClient向 けにハードコードする。 2. または、ユーザーにUIを提示し、ユーザー自身がOAuth Clientを登録した後、 Clientの詳細を入力できるようにする。 ここまでの手順でようやくOAuthを開始するための準備が整った 31
32. © OpenID Foundation Japan OAuthフローの攻撃対策 32
33. © OpenID Foundation Japan Q4 攻撃者によるAccess Tokenの発行をどのように防ぐの？ 33
34. © OpenID Foundation Japan #OpenIDTechNight #AIdentity OAuth Grant Type OAuthでは、Access Tokenを取得するGrant Type（付与タイプ）が規定されている。 MCP Serverは、対象とするユーザーに最も適した Grant Typeをサポートすべきである。 Authorization Code Grant • Clientが人間であるエンドユーザーに代わって行動している場合に使われる。 • 例えばエージェントがSaaSシステムによって実装されたMCPツールを呼び出すなど。 Client Credentials Grant • Clientは人間ではないアプリケーションの場合に使われる。 • 例えば、エージェントが特定の店舗の在庫を確認するために、安全な MCPツールを呼び出すな ど。エンドユーザーになりすます必要がない場合。 今回はAuthorization Code Grantを例に解説する。 34
35. © OpenID Foundation Japan この例では、 MCP Serverが Authorization Serverとしても 機能している 35
36. © OpenID Foundation Japan この例では、 MCP Serverが Authorization Serverとしても 機能している Access Tokenなしのアクセスで返却される401 Unauthorizedを契機にOAuthフローを開始 36
37. © OpenID Foundation Japan この例では、 MCP Serverが Authorization Serverとしても 機能している ClientはUser-Agentのリダイレクトを利用して Authorizationリクエストする 37
38. © OpenID Foundation Japan この例では、 MCP Serverが Authorization Serverとしても 機能している Authorization ServerはUser-Agentのリダイレクトを 利用してAuthorization CodeをClientに返却 38
39. © OpenID Foundation Japan この例では、 MCP Serverが Authorization Serverとしても 機能している TokenリクエストでAuthorization Codeを送信し Access Tokenを交換する 39
40. © OpenID Foundation Japan この例では、 MCP Serverが Authorization Serverとしても 機能している Access Tokenを付加してMCP Protocol開始 40
41. © OpenID Foundation Japan #OpenIDTechNight #AIdentity PKCEとは • Proof Key for Code Exchange（PKCE、ピクシーと発音）とは、 Authorization Codeの横取り攻撃を防止 するための仕組み。 • Clientがランダムなcode_challengeとそのハッシュ値である code_verifierを生成する。（この2つのパラ メーターがProof Keyとなる） • code_challengeは初期の認証リクエストとともに送信され、 Authorization ServerはClientが Authorization CodeをTokenと交換する際にcode_verifierを検証する。 • これにより攻撃者に Authorization Codeが傍受されてもcode_verifierなしではTokenの交換はできなくな る。 MCP Authorization Server MCP Client Attacker authorization_code + code_verifier authorization_code authorization_code Access Token Access Token 41 Latest draft
42. © OpenID Foundation Japan この例では、 MCP Serverが Authorization Serverとしても 機能している Authorizationリクエストでcode_challengeを送信し Authorization Serverに保存 Tokenリクエスト時にcode_verifierを検証し 攻撃者によるAuthorization Codeの置き換えを防止 42
43. © OpenID Foundation Japan 漏洩リスク低減策 43
44. © OpenID Foundation Japan Q5 Access Tokenに付与した権限はコントロールできるの？ 44
45. © OpenID Foundation Japan Authorizationリクエストと Tokenリクエストで Access Tokenの権限をコントロール 45
46. © OpenID Foundation Japan #OpenIDTechNight #AIdentity Clientが使用するMCP Serverを明示する • 多数のMCP Serverの使用権限が付与された Access Tokenはリスクが増加するため、 Access Token発 行のフローの中で使用する scope（権限）やMCP Serverを明示しコントロールする。 • Resource Indicators for OAuth 2.0 (RFC 8707)に従い、ClientはAuthorization Serverに対して resourceパラメーターで使用する MCP Serverを明示的に指定する。 GET /authorize?response_type=code &client_id=s6BhdRkqt3 &state=tNwzQ87pC6llebpmac_IDeeq-mCR2wLDYljHUZUAWuI &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb &scope=calendar%20contacts &resource=https%3A%2F%2Fcal.example.com%2F &resource=https%3A%2F%2Fcontacts.example.com%2F HTTP/1.1 Host: api.example.com Authorizationリクエスト MCP Clientが使用する MCP Serverのresourceを指定する 今回の例ではscopeと resourceは対となっている 46 draft
47. © OpenID Foundation Japan #OpenIDTechNight #AIdentity 最小限の権限が付与されたAccess Tokenを発行 Access Tokenレスポンス POST /token HTTP/1.1 Host: api.example.com Authorization: Basic czZCaGRSa3F0Mzpoc3FFelFsVW9IQUU5cHg0RlNyNHlJ Content-Type: application/x-www-form-urlencoded grant_type=authorization_code &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb &code=10esc29BWC2qZB0acc9v8zAv9ltc2pko105tQauZ &resource=https%3A%2F%2Fcal.example.com%2F HTTP/1.1 200 OK Content-Type: application/json Cache-Control: no-cache, no-store { "access_token":"eyJhbGciOiJFUzI1NiI…", "token_type":"Bearer", "expires_in":3600, "refresh_token":"4LTC8lb0acc6Oy4esc…", "scope":"calendar" } Access Tokenリクエスト 指定したresourceのカレンダーscopeのみが 付与されたAccess Tokenが取得できる カレンダーのみの resourceを指定する • Tokenリクエスト時にresourceパラメーターにMCP Serverを指定する。 • Authorization Codeを使って必要なscopeのみが付与されたAccess Tokenの発行が可能。 47
48. © OpenID Foundation Japan #OpenIDTechNight #AIdentity DownscopeによるAccess Token漏洩リスクの低減 Access Tokenレスポンス POST /token HTTP/1.1 Host: api.example.com Authorization: Basic czZCaGRSa3F0Mzpoc3FFelFsVW9IQUU5cHg0RlNyNHlJ Content-Type: application/x-www-form-urlencoded grant_type=refresh_token &refresh_token=4LTC8lb0acc6Oy4esc1Nk9BWC0imAwH7kic16BDC2 &resource=https%3A%2F%2Fcontacts.example.com%2F HTTP/1.1 200 OK Content-Type: application/json Cache-Control: no-cache, no-store { "access_token":"eyJhbGciOiJFUzI1NiI…", "token_type":"Bearer", "expires_in":3600, "scope":"contacts" } Access Tokenリクエスト 指定したresourceの連絡先scopeのみが 付与されたAccess Tokenが取得できる 連絡先のみのresourceを指定する • Refresh TokenによるAccess Token更新も同様にresourceパラメーターを指定することで最小限の権限 が付与されたAccess Tokenを発行可能。 • DownscopeによってAccess Token漏洩リスクを低減する。 48
49. © OpenID Foundation Japan MCP ServerへのAccess Tokenの指定は OAuth 2.1に準ずる 49
50. © OpenID Foundation Japan #OpenIDTechNight #AIdentity Access Tokenの指定形式と検証 • MCP Serverへリクエストを行う際、ClientはOAuth 2.1で定義されているAuthorizationリクエ ストヘッダーフィールドを使用しなければならない。 • Access TokenをURIクエリ文字列に含めてはいけない。 • MCP Serverは、意図されたClientへ発行されたものであるか、無効または期限切れでない か、などOAuth 2.1の仕様に従いAccess Tokenの検証をしなければならない。 50 MCPに定義されているOAuthフロー・攻撃対策・リスク低減策はここまで 最後にユーザー認証に関する提案 GET /mcp HTTP/1.1 Host: mcp.example.com Authorization: Bearer eyJhbGciOiJIUzI1NiIs… Authorization: Bearer <access-token> Bearer Tokenリクエスト形式 MCP Serverリクエスト Latest draft
51. © OpenID Foundation Japan Account Take Over対策 51
52. © OpenID Foundation Japan Q6 どのようにユーザー認証するの？ 52
53. © OpenID Foundation Japan ユーザー認証の仕様は OAuthでは定義されていない 53
54. © OpenID Foundation Japan #OpenIDTechNight #AIdentity OpenID Connectでユーザー認証の連携 • Third-Party Authorization Flowで純粋なリソースアクセスする場合にはユーザー認証は不要だが、 MCP Serverで認証したい場合には OpenID Connectを適用できる。 • MCP Authorization ServerをRelying Party（RP）と見立てて、堅牢な認証システムを提供する OpenID Provider（OP）が提供するOpenID Connectでユーザー認証を連携することで Account Take Overのリスクを低減することができる。 MCP Authorization Server RP OpenID Connect OP Resource Owner End-User User Authentication 54 MCP定義仕様外の提案
55. © OpenID Foundation Japan #OpenIDTechNight #AIdentity MCPにOAuthを適用するにあたってでてくる疑問と回答 Q1 A1 Q2 Authorization Serverをどのように見つけるの？ MCP ServerからProtected Resource Metadataを返却することで特定する Authorization Serverのエンドポイントをどのように見つけるの？ A2 Q3 Authorization ServerからAuthorization Server Metadataを返却することで特定する Clientをどのように登録するの？ A3 Dynamic Client Registration ProtocolでAuthorization ServerにClientを自動登録する Q4 A4 Q5 攻撃者によるAccess Tokenの発行をどのように防ぐの？ OAuth 2.1で必須となっているPKCEでAuthorization Code横取り攻撃を防ぐ Access Tokenに付与した権限はコントロールできるの？ A5 Q6 Resource IndicatorsのDownscopeでAccess Tokenの権限を最小化する どのようにユーザー認証するの？ A6 OpenID Providerが提供するOpenID Connectによってユーザー認証を連携する 55
56. © OpenID Foundation Japan #OpenIDTechNight #AIdentity まとめ • MCPは基本的にMCP Serverであるリソースアクセスで用いられるものであり、 標準的なOAuthのAuthorization FlowとThird-Party Authorization Flowの2つが想定される。 • Clientは多数のMCP Serverへの接続がスケールできるように自動でAuthorization Serverの特定 からClientの登録までを行う。 • MCPのユースケースにはPKCEなどのOAuthのプラクティスがそのまま適用できる。 • MCP Serverのアクセス時にユーザー認証したい要件がある場合に、リソースアクセスとユーザー認 証を同時に行えるOpenID Connectを適用可能である。 56 MCPの標準仕様は現在も更新し続けている 今後の動向をキャッチアップしてセキュリティ対策を講じることが重要
57. © OpenID Foundation Japan EOP 57