Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Keycloakで始めるMCPの認可

 Keycloakで始めるMCPの認可

Avatar for Hiroyuki Wada

Hiroyuki Wada

March 01, 2026
Tweet

More Decks by Hiroyuki Wada

Other Decks in Programming

Transcript

  1. 所属 株式会社野村総合研究所 専門 認証、認可、ID管理/ガバナンス 活動 Keycloak、midPointなどのOSSコントリビューター Cloud Native Security Japan

    オーガナイザー 「認証と認可 Keycloak入門」などの書籍・記事の執筆 GitHub: @wadahiro / X: @wadahiro 自己紹介 和田 広之 (Hiroyuki Wada) Copyright (C) Nomura Research Institute, Ltd. All rights reserved. 1
  2. AIアプリケーションと外部ツール/データソースをつなぐオープンプロトコル Anthropicが提唱、2025年12月にLinux Foundation (Agentic AI Foundation) に寄贈 ローカルMCPサーバー: MCPホストと同一マシン上で動作 リモートMCPサーバー:

    ネットワーク経由でアクセス 出所: https://modelcontextprotocol.io/docs/getting-started/intro    https://modelcontextprotocol.io/docs/learn/architecture MCP (Model Context Protocol) とは Copyright (C) Nomura Research Institute, Ltd. All rights reserved. 4
  3. MCPクライアントはOAuthクライアント、 MCPサーバーはOAuthリソースサーバーとして動作 MCPサーバーと認可サーバーは独立 → Keycloakなど既存の認可サーバーを使える 認可サーバー MCP サーバー (OAuth リソースサーバー)

    MCP クライアント (OAuth クライアント) 1. OAuth 2.1 による認可 ( 認可コードフロー) 2. アクセストークン発行 3. アクセストークンでアクセス 4. レスポンス リモートMCPサーバーの認可フロー概要 Copyright (C) Nomura Research Institute, Ltd. All rights reserved. 6
  4. バージョンが上がるにつれ、OAuth 2.1に加え関連仕様が次々と追加されている 2024-11-05 認可の仕様なし 2025-03-26 OAuth 2.1 RFC 8414 OAuth

    2.0 Authorization Server Metadata (認可サーバー情報の公開) RFC 7591 OAuth 2.0 Dynamic Client Registration Protocol (DCR) (クライアントの動的登録) 2025-06-18 + RFC 9728 OAuth 2.0 Protected Resource Metadata (MCPサーバーのメタデータ公開) + RFC 8707 Resource Indicators for OAuth 2.0 (アクセストークンの利用先制限) 2025-11-25 + OAuth Client ID Metadata Document (CIMD) (メタデータURL公開によるクライアント動的登録) + OpenID Connect Discovery 1.0 + Step-up Authorization (スコープ不足時の追加認可) RFC 7591 DCR が SHOULD → MAY に (CIMDが代わりにSHOULD) MCPの認可仕様の変遷 Copyright (C) Nomura Research Institute, Ltd. All rights reserved. 7
  5. 通常のOAuthアプリとは異なるMCPの特性 認可サーバーが事前に分からない MCPサーバーのURLから認可サーバーを自動発見する必要がある → ディスカバリー (RFC 9728 / RFC 8414

    / OIDC Discovery) client_idが認可サーバーに事前登録されていない 接続先が動的に決まるため、クライアントを事前登録できない → クライアント動的登録 (RFC 7591 / CIMD) 悪意あるMCPサーバーが紛れ込むリスク ユーザーが自由にMCPサーバーを追加できるため、アクセストークンの 流用を防ぐ必要がある → アクセストークンの利用先制限 (RFC 8707) ※ 各フローの詳細シーケンス図はAppendixに掲載 なぜこれだけの仕様が必要か 通常のOAuthアプリ MCP Copyright (C) Nomura Research Institute, Ltd. All rights reserved. 8
  6. DCR (Dynamic Client Registration, RFC 7591) 認可サーバーにクライアント情報をPOSTして動的に登録 メタデータは自己申告 → 検証手段が限定的

    同じアプリでもユーザー/デバイスごとに新規登録 → 登録が無尽蔵に増加 CIMD (OAuth Client ID Metadata Document) クライアントのHTTPS URL自体がclient_idになる 認可サーバーがURLからメタデータを取得・検証 → HTTPSドメインの所有が信頼の根拠 同じアプリなら同じclient_id → 登録の増殖が起きない ⚠ CIMDの注意点: クライアントの信頼性の検証手段が未定義 → 許可リスト等による補完が必要 DCRからCIMDへ Copyright (C) Nomura Research Institute, Ltd. All rights reserved. 9
  7. MCPコアとは独立した拡張仕様(MCP Authorization Extensions)の策定も進んでいる https://modelcontextprotocol.io/extensions/auth/overview Client Credentials Flow ユーザー操作なしのマシン間認証(M2M)をサポート Enterprise-Managed Authorization

    Profile 企業の既存IdPと連携し、個別のMCPサーバーごとの認可操作を省略 Identity Assertion JWT Authorization Grant (ID-JAG) を中核技術として使用 MCPの認可仕様の今後 Copyright (C) Nomura Research Institute, Ltd. All rights reserved. 10
  8. MCP Authorization仕様はMCPクライアント - MCPサーバー間の認可の仕組み MCPサーバーから外部API(GitHub, Slack等)へのアクセスはMCP Authorizationのスコープ外 仕様上の禁止事項(Token Passthrough禁止) MCPクライアントはMCPサーバーの認可サーバーが発行したトークン以外を送信してはならな

    い MCPサーバーはMCPクライアントから受け取ったトークンを外部APIに転送してはならない 外部サービスの認可には URL Mode Elicitation を使う MCPクライアントを経由せず、ブラウザ上でAPIキー入力やOAuth認可を安全に処理 https://modelcontextprotocol.io/specification/2025-11-25/client/elicitation (補足) MCPサーバーから外部APIへのアクセス Copyright (C) Nomura Research Institute, Ltd. All rights reserved. 11
  9. Red Hat主導で開始し、現在はCNCF Incubatingプロジェクトとしてベンダー中立的な環境で開発 Apache License 2.0 MCP公式の認可チュートリアルで認可サーバーとして使用 https://modelcontextprotocol.io/docs/tutorials/security/ authorization 主要機能

    認証: パスワード・OTP・パスキーに対応 認可: OAuth2 に対応 フェデレーション: OIDC/SAML に対応 管理: ユーザー・グループ管理、監査ログ Keycloakとは ID管理・アクセス管理 (IAM) のOSS Copyright (C) Nomura Research Institute, Ltd. All rights reserved. 13
  10. Standard 2025-11-25 2025-06-18 2025-03-26 Keycloak OAuth 2.1 Authorization Framework MUST

    MUST MUST Supported OAuth 2.0 Authorization Server Metadata (RFC 8414) MUST MUST MUST Supported Resource Indicators for OAuth 2.0 (RFC 8707) MUST MUST — Not supported OAuth 2.0 Dynamic Client Registration (RFC 7591) MAY SHOULD SHOULD Supported OAuth Client ID Metadata Document SHOULD — — Not supported MCP Version Conformance 2025-03-26 Supported 2025-06-18 Partially Supported without Resource Indicators for OAuth 2.0 2025-11-25 Partially Supported without Resource Indicators for OAuth 2.0 and OAuth Client ID Metadata Document KeycloakのMCP認可の対応状況 出所: https://www.keycloak.org/securing-apps/mcp-authz-server ※ RFC 9728 OAuth 2.0 Protected Resource Metadata はResource Server(MCPサーバー)側の仕様のため記載なし Copyright (C) Nomura Research Institute, Ltd. All rights reserved. 14
  11. RFC 8707サポートまでの暫定的な代替手段 方法1: クライアントスコープ + Audienceマッパー(公式ドキュメント) スコープにAudienceマッパーを設定し、MCPサーバーURLを静的に紐付け 詳細: https://www.keycloak.org/securing-apps/mcp-authz-server 注意:

    同じスコープを持つ複数MCPサーバー環境ではトークン流用のリスクあり 方法2: カスタムプロトコルマッパーで対応 認可リクエスト時の resource パラメータの値を動的に aud クレームにマッピング 参考実装: https://github.com/wadahiro/keycloak-resource-indicator-audience-mapper RFC 8707 Resource Indicators 未対応の回避策 Copyright (C) Nomura Research Institute, Ltd. All rights reserved. 15
  12. RFC 8707 Resource Indicators 対応 (https://github.com/keycloak/keycloak/pull/45739) resource パラメータをアクセストークンの aud クレームにマッピング

    リソースパラメータのバリデーション(クライアントポリシー) 認可リクエスト〜トークンリクエスト間の一貫性チェック CIMD対応 (https://github.com/keycloak/keycloak/pull/45285) Merged 2025-02-23 CIMDの取得・検証・永続化(エフェメラルは今後対応予定) 許可ドメインリストによるクライアントの信頼性検証 Enterprise-Managed Authorization (ID-JAG) 対応 (https://github.com/keycloak/keycloak/pull/46048) ID-JAGトークンによるアクセストークン発行をサポート 開発状況 Copyright (C) Nomura Research Institute, Ltd. All rights reserved. 16
  13. MCPクライアントは事前設定なしで認可サーバーを自動発見できる 認可サーバー MCP サーバー MCP クライアント RFC 9728 OAuth 2.0

    Protected Resource Metadata RFC 8414 OAuth 2.0 Authorization Server Metadata OpenID Connect Discovery 1.0 にfallback alt [404 の場合] 1. リクエスト 2. 401 + Resource Metadata URL 3. Protected Resource Metadata 取得 4. 認可サーバーURL/ スコープ等 5. Authorization Server Metadata 取得 5'. OpenID Connect Discovery 取得 6. エンドポイント情報 認可フローの詳細: ディスカバリー Copyright (C) Nomura Research Institute, Ltd. All rights reserved.
  14. ディスカバリーで認可サーバーを特定した後、クライアント登録を行う 認可サーバーに動的に登録してclient_idなどを取得 以後は通常の認可コードフローを実行 ただしバージョン2025-11-25でSHOULD → MAYに変更(CIMDが代わりにSHOULD) 認可サーバー MCP サーバー MCP

    クライアント ( ディスカバリー完了) RFC 7591 OAuth 2.0 Dynamic Client Registration Protocol ( 認可コードフローへ) POST /register ( クライアント情報) client_id など 認可フローの詳細: クライアント動的登録 (DCR) Copyright (C) Nomura Research Institute, Ltd. All rights reserved.
  15. クライアントのHTTPS URL自体がclient_idとなる 認可サーバーがURLからメタデータをfetchして検証・登録 同じURLなら同じclient_idのため、DCRのような登録の増殖が起きない 認可サーバー メタデータURL MCP クライアント ( ディスカバリー完了)

    認可コードフロー w/ OAuth Client ID Metadata Document 検証・クライアント登録 ( 認可コードフロー 続き) 認可リクエスト (client_id= メタデータURL) メタデータ取得 (HTTP GET) メタデータJSON (client_id, redirect_uris 等) 認可レスポンス ( 認可コード) 認可フローの詳細: クライアント動的登録 (CIMD) Copyright (C) Nomura Research Institute, Ltd. All rights reserved.
  16. トークンの利用先がMCPサーバー単位で制限され、別のMCPサーバーへのトークン流用を 防止 認可サーバー MCP サーバー MCP クライアント ( クライアント登録完了) OAuth

    2.1 + RFC 8707 Resource Indicators for OAuth 2.0 aud 検証 ( 自分宛か確認) 認可リクエスト (resource=MCP サーバーURL) 認可コード トークンリクエスト ( 認可コード + resource=MCP サーバーURL) アクセストークン発行 (aud=MCP サーバー) トークンでアクセス レスポンス 認可フローの詳細: アクセストークンの利用先制限 Copyright (C) Nomura Research Institute, Ltd. All rights reserved.