「Keycloakで始めるMCPの認可」― Cloud Native Security Japan ミートアップ登壇レポート

はじめに

こんにちは、NRIの和田です。
2026年2月25日（水）に開催された「CNCJ: 認証認可セキュリティミートアップ: Identity Next」にて、「Keycloakで始めるMCPの認可」というタイトルで登壇しました。本記事ではイベントの様子と発表内容をご紹介します。

Cloud Native Security Japan (CNSJ) とは

Cloud Native Security Japan（以下、CNSJ）は、CNCF（Cloud Native Computing Foundation）の日本初の公式コミュニティ「Cloud Native Community Japan（CNCJ）」のセキュリティ専門サブチャプターとして、2024年5月に発足した非営利コミュニティです。クラウドネイティブにおけるセキュリティ分野の技術革新を促すために、日本からのOSSコントリビューションを活性化させることを目的としています。NRIからは設立当初よりオーガナイザーとして相田と和田が参画しており、今回のミートアップでは相田が司会を務めました。

CNSJでは3か月に一度のペースでミートアップを継続的に開催しており、認証認可、コンテナランタイムセキュリティ、サプライチェーンセキュリティなど、毎回テーマを設定してクラウドネイティブにおけるセキュリティトピックを扱っています。今回は「Identity Next」と題し、認証・認可の最新動向にフォーカスした回でした。

イベント概要：

イベント名：CNCJ: 認証認可セキュリティミートアップ: Identity Next
主催：Cloud Native Security Japan
開催日：2026年2月25日（水）18:30〜21:00
会場：ガーデンテラス紀尾井町17F セミナールーム / オンライン（ハイブリッド）

当日のセッション

今回は4つのセッションが行われました。

時間	セッション	発表者
19:10	入門DBSC	Red Hat 能島氏
19:35	AIエージェントの認証・認可	LINE Yahoo 矢野氏
20:10	Keycloakで始めるMCPの認可	野村総合研究所和田
20:35	Web「ID連携」から、自律型AIの「権限管理」へ	freee 寺原氏

AIエージェント時代の認証・認可に関するセッションが並ぶ中、能島氏の「入門DBSC」はブラウザセキュリティの新しい取り組みを紹介するセッションでした。パスキーの普及により認証自体が強固になると、攻撃の対象はセッション管理に移ってきます。DBSC（Device Bound Session Credentials）はセッションをデバイスに紐付けることでこの脅威に対抗する仕組みで、Identityの「次」を考える上で示唆に富む内容でした。
矢野氏の「AIエージェントの認証・認可」では、AIエージェントがユーザーの代理として振る舞う際のIdentity Chainingに焦点を当て、KeycloakとAthenzをRFC 8693（Token Exchange）で連携させるアプローチが紹介されました。
寺原氏の「Web「ID連携」から、自律型AIの「権限管理」へ」では、OpenIDファウンデーション・ジャパンの活動紹介とともに、AIエージェント時代のIdentity Managementという新たなテーマが取り上げられました。
いずれのセッションも「Identityの次」を見据えた内容で、活発な質疑応答が交わされていました。

発表内容の紹介

私のセッションでは、リモートMCPサーバーの認可をどう実装すればよいかをテーマに発表しました。自社サービスを外部向けにMCPサーバーとして公開するケースだけでなく、社内の既存資産をMCPサーバー経由で利用可能にしてAI活用を進めるというエンタープライズのユースケースも視野に入れた内容です。

背景: リモートMCPサーバーと認可の課題

MCP（Model Context Protocol）は、AIアプリケーションと外部ツール/データソースをつなぐオープンプロトコルです。AtlassianやNotionなどの主要SaaSベンダーが自社サービスのリモートMCPサーバーを公開し始めているほか、社内システムをMCPサーバー経由でAIエージェントから利用可能にするといった活用も広がりつつあります。

リモートMCPサーバーにはOAuth 2.1ベースの認可の実装が必要ですが、通常のOAuthアプリとは異なり「ユーザーが接続先を自由に追加できる」というMCP特有の性質から、認可サーバーの自動発見やクライアントの動的登録、トークン流用防止など、追加の仕様への対応が求められます。さらにMCPのバージョンが上がるたびに要件が増え続けており、自前で追従するのは現実的ではありません。

Keycloakで何がカバーでき、何が足りないか

そこで、OSSの認可サーバーであるKeycloakを使うことで何がカバーできるかを整理しました。Keycloakは既にOAuth 2.1の基本フローやクライアント動的登録（DCR）に対応しており、MCP公式の認可チュートリアルでも認可サーバーとして採用されています。

一方で、最新のMCP仕様で求められるRFC 8707（Resource Indicators）やOAuth Client ID Metadata Document（CIMD）への対応はまだ途上です。セッションでは、RFC 8707未対応の回避策（カスタムプロトコルマッパーによる実装）や、KeycloakのGitHub上で進行中のPull Requestの状況も紹介しました。実際にCIMD対応のPull Requestは発表の2日前にマージされたばかりで、開発が活発に進んでいることをお伝えできました。

デモ

最後に、Visual Studio CodeとCIMD対応版のKeycloakを使ったデモを実施しました。Visual Studio Code側にはMCPサーバーのURLだけを設定し、認可サーバーの情報もクライアントも事前登録なしでMCP認可が完了する様子をご覧いただきました。

当日の発表資料はconnpassのイベントページで公開されています。

さいごに

今回のミートアップでは、AIエージェント時代における認証・認可の新しい課題が各セッションで共通して語られていました。MCPの認可仕様は急速に進化中ですが、Keycloakのようなコミュニティ主導のOSSを活用することで、変化への追従をコミュニティの力に委ねられるのは大きなメリットだと感じています。
NRIでは、Keycloakをはじめとする認証認可基盤の導入支援を行っています。MCPの認可やID基盤についてお悩みの方は、ぜひお気軽にお問い合わせください。

IAM に関するソリューションはこちら