Keycloak Realm Inspector

KeyConf 2026のClient ID Metadata Documents（draft-ietf-oauth-client-id-metadata-document-02）に関するトークのための、純粋にOAuth 2.0保護リソースであるMCPサーバー。

何も発行しません — /authorizeも/tokenもクライアントシークレットもありません。Keycloakがトークンを発行します。このサーバーはKeycloakのJWKSに対してトークンを検証し、RFC 9728ディスカバリーを提供し、リソースサーバーの内部からCIMDを可視化する3つのツールを公開します。

意図的に分離された三者

このサーバーはクライアントのメタデータドキュメントをホストせず、読み取らず、フェッチもしません。/client-metadata.jsonルートもローカルコピーもありません。Keycloakは/authorize中にそのURLをネットワーク経由でフェッチします。このコードベースでは、URLはazpクレームに含まれる不透明な文字列としてのみ現れます — それがデモの要点であり、ドキュメントが別のポートの別プロセスで提供される理由でもあります。

Related MCP server: mcpauth

実行

Keycloakが起動しており、レルムが作成され、CIMDクライアントポリシーがすでに適用されていることを前提としています。クライアント、そのメタデータドキュメント、トークンヘルパーは、このリポジトリと同じ階層の../cimd-demo/auth-server/にあります。

# terminal 1 — the client's document. Its own party, its own port.
cd ../cimd-demo/auth-server && python -m http.server 9000

# terminal 2 — the resource server
pip install -r requirements.txt
python server.py                     # http://localhost:9001

# terminal 3 — get a token, then point an MCP client at :9001/mcp
cd ../cimd-demo/auth-server && python get-token.py

フロー

1. クライアントはトークンなしで/mcpを呼び出し、WWW-Authenticate: Bearer ..., resource_metadata="…"付きの401を受け取ります。

2. クライアントはそれに従って/.well-known/oauth-protected-resource/mcpにアクセスし、どの認可サーバーが有効なトークンを発行するかを学習します。

3. クライアントはメタデータドキュメントのURLをclient_idとして使用して、Keycloakに対して直接認証します。KeycloakはそのURLをフェッチしてクライアントを実体化します。

4. クライアントはベアラートークンで/mcpを再試行します。

RFC 9728 §3.1はwell-knownセグメントをホストとリソースパスの間に置くため、ディスカバリードキュメントは/.well-known/oauth-protected-resource/mcpにあります。素のパスは404です。

ツール

• whoami() — 呼び出し元のトークンからのsub、preferred_username、azp、scope、exp、issに加えて、registered_via_cimd。トークンのみを読み取ります。Keycloakへの呼び出しがないため、管理者の認証情報が間違っていても機能します。

• list_clients(only_cimd=False) — レルムのクライアント。URL形式のclient_idを先頭にソートして、呼び出し元のクライアントが最初の行に来るようにします。

• get_client_metadata(client_id) — Keycloak自身によるクライアントの表現。これはKeycloakの派生ビューであり、公開されたドキュメントではありません。

CIMDはhttp://またはhttps://で始まるclient_idによって検出されます。URL形式のclient_idがその目印です。

get_client_metadataは、返す前にsecretとregistrationAccessTokenを除去します。どちらも有効なベアラー資格情報であり、この出力はプロジェクターに映され、録画にも入ります。

既知のギャップが2つ

RFC 8707リソースインジケーター。 audience=は存在しますが、JWTVerifierではコメントアウトされています。トークンをオーディエンス制限するには、クライアントが/authorizeでresourceを送信する必要がありますが、Keycloak 26.7のCIMDパスはまだそれを尊重していません（keycloak#45106、keycloak#45284）。そのため、トークンはKeycloakの通常のaccountオーディエンスを保持し、このサーバーはオーディエンス制限できません。意図的に見えるようにしています。

スコープ強制なし。 required_scopesが未設定のため、レルムからの署名が有効で有効期限が切れていないトークンはすべて受け入れられます — admin-cliパスワードグラントからのトークンも含みます。これはステージで役立ちます：管理者トークン（azpは不透明な文字列）でwhoami()を実行し、CIMDトークン（azpはURL）でもう一度実行します。同じツール、同じサーバー、違いは1つのフィールドだけです。これはまた、手にしているトークンがどれかを確実に把握している必要があることも意味します。

設定

すべてos.getenvで、localhostをデフォルトとしています。

KEYCLOAK_ISSUERとKEYCLOAK_JWKS_URIは互いに導出されるのではなく、個別に設定可能です：KubernetesではイシュアーがパブリックURLであるため、issはクライアントが見るものと一致しますが、JWKSフェッチはクラスター内のServiceに向けるべきです。

fastmcpは正確に固定されています。認証サーフェスは移り変わります — resource_server_urlはbase_urlになり、AccessToken.claimsは2.11.3で追加されました — そしてallowed_client_redirect_urisは、ドキュメントが示しているにもかかわらず、どのリリースでもRemoteAuthProviderのパラメーターではありません。これは、このサーバーが使用しないOAuthProxyに属します。