CIMD ― client_idを、公開された名刺のURLにする

発行: アニメモ公式
版: 第2版
改訂: 2026/9/11
コマ: 全7

Client ID Metadata Document草案-02を図解。公開・取得・照合・鍵の所持確認を分けて学びます。2026-09-10確認。

アプリのIDが、自己紹介文書のURLになる

CIMDはOAuth Client ID Metadata Documentのことです。クライアントがHTTPS URLを client_id として示し、認可サーバーがそのURLからクライアント情報のJSONを取得する仕組みです。

ここでは draft-ietf-oauth-client-id-metadata-document-02（2026年7月6日版） を、2026年9月10日に確認して説明しています。RFCとして確定した規格ではなく、変更される可能性がある草案です。IETF草案 -02

図の「公開された名刺」はアプリの情報を示します。利用者の身分証でも、認証用の秘密でもありません。

クライアントが、JSONを公開する

例えば印刷アプリは、次のような文書を https://print.example/client.json で公開します。.example は説明用の予約ドメインです。

json

{
  "client_id": "https://print.example/client.json",
  "client_name": "Print Studio",
  "redirect_uris": ["https://print.example/callback"],
  "token_endpoint_auth_method": "none"
}

これはパブリッククライアントの説明例です。none はクライアント認証を行わないという意味で、利用者の認証やOAuthの検査が不要になる意味ではありません。

文書はJSONの200応答で提供し、内部の client_id は文書を取得したURLと文字列として一致させます。草案 §4–5

認可サーバーが、URLから情報を読む

クライアントは認可リクエストの client_id に文書のURLを入れます。CIMDに対応した認可サーバーは、そのURLへアクセスして情報を取得できます。

URLにはHTTPSとパスが必要です。ユーザー情報やフラグメントなど、草案で禁止された要素を含めません。文書取得時にはHTTPリダイレクトを自動追跡しません。

図では、最初にURLの札が認可サーバーへ移動し、サーバーから公開文書への取得矢印が現れます。クライアントが勝手に渡したJSONを、そのまま登録情報として信用する説明ではありません。

文書を読んだ後にも、照合がある

認可サーバーは、取得URLとJSON内の client_id を照合します。さらに、リクエストの redirect_uri が許可された戻り先と一致するかなど、OAuth側の検査を行います。

HTTPSのURLが一致しても、そのアプリが善良であることまで証明されるわけではありません。表示名やロゴは自己申告の情報です。

図では三つの札を並べます。「取得URL」「文書内のID」「戻り先の登録」の確認を、ログイン成功や無条件の認可と混同しないでください。草案のセキュリティ考慮事項

公開文書へ、秘密の鍵を書かない

CIMDは公開される文書です。この草案では client_secret や秘密鍵素材を含めません。共有秘密に基づくクライアント認証方式も使えません。

公開鍵は jwks や jwks_uri などで示せます。機密クライアントが private_key_jwt を使うなら、対応する秘密鍵による署名で鍵の所持を示します。公開文書が見つかっただけで、リクエストの送信者を認証したことにはなりません。

図では公開鍵が文書へ入り、秘密鍵はクライアント側に残ります。草案 §4.1・§8.2

URLを取りに行く処理にも、境界が必要

外部から指定されたURLへサーバーがアクセスするので、SSRFへの対策が必要です。内部ネットワークやメタデータサービスへのアクセス、DNSの変化、過大な応答などを考慮します。

対応の有無は、認可サーバーのメタデータにある client_id_metadata_document_supported で確認できます。非対応のサーバーが自動的にCIMDを受け入れるわけではありません。

CIMDは事前登録や動的クライアント登録を減らせる選択肢であり、全システムで置き換えを強制する仕組みではありません。草案 §6–8

確認：CIMDを公開すれば、利用者のログインも完成する？

答えはいいえです。CIMDが扱うのは、認可サーバーがクライアントの情報を得る方法です。利用者の認証、許可の判断、コード交換、APIでの権限検証は、それぞれの手順として残ります。

比較すると、OAuthはアクセスの委譲、OIDCは認証結果の伝達、JWTはデータ形式、CIMDはクライアント情報の発見方法です。

図の最後では「公開された名刺」が通常のOAuthの流れにつながります。導入時には、相手の対応状況とIETFの最新版・進捗を確認してください。