MCP OAuth認証のCIMD・DCR移行ガイド｜iss・scope・resource・PKCEの確認順

先に結論：MCP認証はCIMDかDCRかだけを選ぶ作業ではない

MCP 2026-07-28のAuthorization仕様を実装するときは、登録方式だけでなく、どのtransportを使うか、Protected Resource Metadataからどのauthorization serverを発見するか、issuerとcredentialをどう結びつけるか、どのresourceとscopeを要求するか、tokenをどう検証するかまで分けて確認します。CIMD（Client ID Metadata Documents）は新しい接続先での候補、DCR（Dynamic Client Registration）は後方互換の選択肢ですが、どちらを選んでもPKCE、redirect URI、audience、token保管の確認は残ります。

まず登場人物を4つに分ける

MCP serverとauthorization serverは同じ運営主体とは限りません。公式仕様でも、authorization serverはresource serverと別の場所に置けると説明されています。接続先URLとissuerを一つの文字列として扱わず、どのserverが何を発行したかを記録します。

登録方式は3つ：CIMD・事前登録・DCR

複数方式に対応するclientの優先順位は、pre-registration、CIMD、DCR、利用者入力の順です。接続先のmetadataにCIMD対応があるか、DCRのregistration_endpointがあるかを確認し、DCRを最初から固定の前提にしない設計にします。

CIMDで最低限確認すること

• client metadata documentをHTTPS URLで公開し、client_id URLにpathを持たせる
• metadataのclient_idとdocument URLを完全一致させる
• client_name、redirect_urisなど必須項目をそろえる
• Authorization server metadataのclient_id_metadata_document_supportedを確認する
• redirect URIをmetadataに固定し、接続先が完全一致で検証することを確認する
• 公開metadataが更新されたときのcache、差し替え、削除、監査方法を決める

{
  "client_id": "https://app.example.com/oauth/client-metadata.json",
  "client_name": "Example MCP Client",
  "redirect_uris": [
    "https://app.example.com/oauth/callback"
  ],
  "grant_types": ["authorization_code"],
  "response_types": ["code"],
  "token_endpoint_auth_method": "none"
}

DCRは非推奨・後方互換の選択肢として扱う

2026-07-28のClient Registration仕様では、DCRはdeprecatedで、新しい実装はCIMDを使うべき選択肢として整理されています。一方で、CIMDに対応しないauthorization serverとの後方互換のため、DCRは利用可能な選択肢として残っています。DCRを使う場合は、registration endpointの存在だけでなく、発行されたclient credentialをどのissuerに結びつけるか、再登録条件、保存場所、削除方法を記録します。

DCRでloopback redirect errorが出るときはapplication_typeを見る

OIDC対応のauthorization serverがredirect URIをapplication_typeで制約する場合、desktop、mobile、CLI、loopback hostを使うnative clientはapplication_type: nativeを指定する必要があります。web用の既定値webのままだと、loopback redirectが拒否されることがあります。非OIDC serverでは無視される場合もあるため、エラー文だけで全MCPに共通する原因と決めつけず、authorization server metadataと登録仕様を確認します。

Authorization Server Discoveryは401から始まる

MCP serverはProtected Resource Metadataによって、関連するauthorization serverの場所をclientへ知らせます。clientは401 UnauthorizedのWWW-Authenticate headerにあるresource_metadataを優先し、なければMCP endpointに対応するwell-known URIを確認します。その後、authorization server metadataまたはOpenID Connect Discoveryからendpointと対応機能を取得します。

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource", scope="files:read"

• WWW-Authenticateのresource_metadata URLを読み、authorization_serversを確認する
• 複数のauthorization serverがある場合も、issuerごとにregistration stateとtokenを分ける
• well-knownから取得したmetadataのissuerが、取得元から組み立てたissuerと一致するか検証する
• metadataのissuerが別ドメインや別tenantを指していたら、接続を続けず原因を確認する
• authorization serverを変えたとき、別issuerのcredentialを再利用しない

issはauthorization responseのissuer混同を防ぐ

MCPのAuthorization仕様では、clientは認証開始前に検証済みmetadataからissuerを記録し、PKCE verifierやstateと同じrequest recordに関連付けます。authorization responseにissが含まれる場合は記録済みissuerと比較し、metadataがiss対応を宣言しているのにissがない場合はresponseを拒否します。文字列比較の前にhostや末尾slashを勝手に正規化しない点も重要です。

resourceはtokenの行き先を明示する

MCP clientはauthorization requestとtoken requestの両方にresource parameterを含め、対象となるMCP serverのcanonical URIを指定します。これにより、別のresource向けに発行されたtokenをMCP serverが受け入れるリスクを下げます。接続先のURL、path、末尾slashを仕様のcanonical URIとして一貫させ、clientとserverで別の表記を使わないようにします。

authorization request: resource=https%3A%2F%2Fmcp.example.com
token request:         resource=https%3A%2F%2Fmcp.example.com

scopeは最小権限とstep-upを一緒に設計する

初回認証では、401のWWW-Authenticateにあるscope challengeを優先し、必要な権限だけを要求します。scopeが不足した状態で操作した場合、serverは403 Forbiddenとinsufficient_scopeのchallengeを返し、clientは既存scopeと今回必要なscopeのunionで再認証するstep-upを検討します。無制限に再試行せず、scope upgradeの回数と対象resourceを記録して停止条件を設けます。

token・PKCE・redirect URIの最低限

• access tokenはAuthorization headerで送る。URI query stringへ入れない
• MCP serverはtokenのaudienceと発行元を検証し、自分向けでないtokenを受け入れない
• authorization code flowではPKCEを使い、S256を利用できる場合はS256を選ぶ
• authorization server endpointはHTTPS、redirect URIはloopback hostまたはHTTPSに限定する
• redirect URIは登録値との完全一致を確認し、stateの欠落・不一致を受け入れない
• refresh tokenは安全に保存し、発行されると決めつけず、ログに実値を残さない

401・403・redirect errorの切り分け

実装前のMCP OAuthチェックリスト

• HTTP-based transportかstdioかを記録し、対象仕様を分けた
• Protected Resource MetadataのURL、authorization_servers、issuerを保存した
• pre-registration、CIMD、DCRのどれを使うか、接続先の対応を確認した
• CIMDのHTTPS URL、client_id完全一致、redirect_uris、metadata更新を確認した
• DCRを使う場合はdeprecatedな後方互換経路として、application_typeと再登録を設計した
• authorization responseのiss、state、PKCEを検証し、issuerごとにcredentialを分けた
• authorization/token requestのresourceとscopeを一致させ、最小権限にした
• token audience、token保管、refresh、ログ、上流APIへのpassthrough禁止を確認した
• 401/403、scope不足、metadata不一致、認証server変更時の停止・再登録をテストした

まとめ：認証フローを分割してから移行する

MCP OAuth認証の移行では、CIMDを採用するかDCRを残すかだけを決めず、HTTPとstdioの違い、Protected Resource Metadata、authorization serverのissuer、registration、iss、resource、scope、PKCE、token audienceを分解します。401/403やloopback redirectのエラーも、権限を広げて通すのではなく、仕様の発見・登録・検証順に戻って原因を切り分けます。まずテスト用接続と読み取りscopeで確認し、接続先・SDK・clientの対応がそろってから書き込みや本番へ進めるのが安全です。