MCP Client Credentialsとは？CI/CD・常駐処理で使うOAuth拡張の安全設計
MCPのOAuth Client Credentials extensionを、ユーザー不在のCI/CD・background service・server-to-server向けに整理。JWT assertionとclient secret、scope、token refresh、対応状況の確認順を解説します。
公開 2026.08.09 / 更新 2026.08.09
この記事のポイント
- OAuth Client Credentials extensionは、ユーザーのbrowser consentがないmachine-to-machine認証のためのopt-in拡張
- CI/CD、background service、server-to-server、daemonに向くが、ユーザーの明示同意が必要な処理には通常の認証フローを使う
- JWT Bearer Assertionsとclient secretを比較し、secretの保管・rotation・scope・ログを別々に管理する
- client capabilities、token取得、Authorization header、refresh、server側のsignature・claims・scope検証を確認する
先に結論：Client Credentialsはユーザーの代わりではなく、サービス自身のidentity
MCPのOAuth Client Credentials extensionは、ユーザーがbrowserでログインして同意する通常のAuthorization flowではなく、client自身がauthorization serverへアプリケーションcredentialで認証するための拡張です。ユーザー不在のCI/CD、定期実行するbackground service、server-to-server連携、daemonやlong-running workerがMCP resourceへ接続する用途を想定します。人間が明示的に権限を承認すべき処理へ、ユーザー操作を省くために流用する仕組みではありません。
通常のMCP認証とClient Credentialsを使い分ける
| 観点 | 通常のAuthorization flow | Client Credentials extension |
|---|---|---|
| 認証主体 | resource ownerの同意を受けるclient | サービスまたはアプリケーション自身 |
| ユーザー操作 | browser、login、consentが前提になり得る | ユーザー不在でtokenを取得 |
| 向く処理 | 個人のデータを操作する対話型作業 | CI/CD、定期処理、server-to-server、daemon |
| 権限の意味 | ユーザーが許可したscope | サービスidentityに付与したscope |
| 最初の確認 | redirect、PKCE、issuer、resource、scope | client credential、token endpoint、scope、refresh、rotation |
Client Credentialsを選ぶかどうかは「自動化したいか」だけでなく、誰のデータに対して、誰の意思で操作するかで判断します。CIが自分のテスト用MCP serverを読む用途と、個人ユーザーのメールやファイルを代理操作する用途は、同じMCPでも認証の意味が違います。
使う候補になる4つのシナリオ
- ユーザーがいない時間帯に、background serviceが決められたMCP toolを呼ぶ
- CI/CD pipelineのbuild、test、migration前確認などからMCP serverへ接続する
- 二つのbackend systemをserver-to-serverで連携する
- daemonやlong-running workerが、短いtokenを更新しながらMCP resourceを読む
client capabilitiesで拡張対応を宣言する
公式拡張では、MCP clientがper-request capabilitiesのextensionsに、Client Credentials extensionの識別子を含めて対応を宣言します。MCP 2026-07-28ではrequestごとのmetadataが重要になるため、serverが宣言を受け取ったこと、対応するauthorization経路、対象resourceをログで追えるようにします。
{
"io.modelcontextprotocol/clientCapabilities": {
"extensions": {
"io.modelcontextprotocol/oauth-client-credentials": {}
}
}
}この宣言は、clientが拡張を使えることを伝える境界です。credentialが正しいこと、tokenが有効なこと、serverがtool操作を許可することまでを一つで保証しません。capability、token、scope、server側の検証結果を別々に扱います。
CredentialはJWT assertionとclient secretを比較する
| 方式 | 特徴 | 先に見るリスク |
|---|---|---|
| JWT Bearer Assertion | clientがprivate keyで署名し、authorization serverが公開鍵で検証する。公式ページでは推奨形式 | private keyの保管、署名algorithm、短い有効期限、鍵rotation |
| Client secret | client_idとclient_secretをtoken endpointへ送る比較的単純な方式 | 長期credentialの漏えい、rotation忘れ、ログ・設定への混入 |
JWT assertionの一般的なclaimsには、client IDを示すissとsub、authorization serverのtoken endpointを示すaud、短いexp、iatなどが含まれます。値の意味や署名検証は接続先の仕様に従い、秘密鍵やclient secretの実値をPrompt、repo、ログ、HTMLに出さないようにします。
Client secretを使うなら、漏えい時の前提を先に決める
- secret managerなど、repositoryと実行ログから分離した保管先を使う
- source code、commit、確認用HTML、Issue、CIログへ実値を入れない
- 最低限のscopeと対象MCP serverだけにcredentialを絞る
- 定期rotationと、漏えい疑いが出たときの即時無効化・再発行を決める
- tokenやsecretをdebug log、error report、cacheへ残さない
- 可能ならJWT assertionとの比較を行い、長期secretを配布する箇所を減らす
Client側の実行順：宣言・token・header・refresh
| 段階 | 行うこと | 失敗時に止める理由 |
|---|---|---|
| 1. 宣言 | extension supportをrequest capabilitiesへ含める | serverが未対応なら別のflowを検討する |
| 2. Token取得 | authorization serverからclient credentials grantでtokenを取得する | credential、issuer、scope、token endpointを再確認する |
| 3. 送信 | HTTP requestのAuthorization headerへtokenを入れる | query stringや別serverへ送らない |
| 4. Refresh | expiry前に新しいtokenを取得する | 期限切れtokenの無限retryを止める |
| 5. 監査 | client、server、scope、token expiry、tool、結果を記録する | 何が実行されたか不明な状態で続けない |
Authorization: Bearer <access_token>公式extensionページでは、Client Credentials tokenはuser-delegated tokenより短い寿命になり得るため、expiry前のrefresh処理が必要と説明されています。refreshに失敗したときにscopeを広げて繰り返すのではなく、token endpoint、credential、clock、serverの対応を確認して停止します。
Server側はsignature・claims・scopeを毎回見る
- authorization serverの公開鍵を使ってJWT signatureとclaimsを検証する
- 対象resource、issuer、expiry、必要なscopeを確認する
- toolごとに必要なscopeを分け、tokenがあるだけで全toolを許可しない
- server/discoverでextension supportをadvertiseする場合も、実際のtool権限を別に検証する
- 不正または期限切れtokenを成功扱いせず、監査ログにsecretやtoken実値を残さない
ユーザー不在だからこそ、scopeと停止条件を狭くする
人間のconsent画面がない認証は、実行のたびにユーザーがscopeを見直す機会もありません。最初からread-only、対象resource限定、tool allowlist、実行時間帯、回数上限、失敗時停止を設計します。writeやdeleteを必要としない処理へ広いscopeを付けると、credential漏えい時の影響も大きくなります。
| 制御 | 小さく始める例 | 見直すきっかけ |
|---|---|---|
| scope | read専用、単一resource | 403や作業要件の変化 |
| tool | list/read中心のallowlist | 新tool追加やserver更新 |
| 時間 | 短いjob、固定schedule | 長時間化、timeout増加 |
| 対象 | テスト用repo・sandbox data | 本番dataや外部送信を扱う |
| 停止 | expiry、連続失敗、差分検知でstop | 監査結果、secret rotation、incident |
CI/CDに組み込む前の確認順
- CI runnerが誰のservice identityとして動くかを決める
- secret managerまたは署名鍵の取得経路を確認し、ログとartifactへ出ないことを検証する
- test用MCP serverとread-only scopeでtoken取得・refresh・失敗時停止を確認する
- MCP clientがextensionを宣言し、server側でsignature・claims・scopeが検証されることを確認する
- tool、対象repo、外部送信、branch、PR、deployの境界をjob単位で固定する
- credential rotation、token expiry、authorization server障害、権限不足のテストを行う
- 人間レビューが必要な変更は、Client Credentialsがあっても自動承認にしない
Background serviceとdaemonで見るログ
| ログ項目 | 残す情報 | 残さない情報 |
|---|---|---|
| identity | clientの識別子、対象server、job ID | client secret、private key、access token |
| authorization | issuer、scope名、token expiry、refresh結果 | tokenの実値、authorization code |
| operation | tool名、対象、開始・終了、結果区分 | 送信データの過剰な全文 |
| failure | HTTP status、原因分類、停止理由 | credentialを含むraw header |
Client supportは個別に確認する
公式extensionページでは、Client Credentialsはopt-inで、clientによってsupportが異なると案内されています。MCP serverが対応していても、使うclientやCLIがcapability宣言、token取得、refresh、header送信に対応しているとは限りません。client matrix、SDKの現行版、serverのdiscover response、authorization serverのmetadataを同じ表で確認します。
| 確認対象 | 聞くこと |
|---|---|
| Client / CLI | extensionを宣言し、token refreshまで実装しているか |
| MCP server | token signature、audience、scopeを検証し、supportをadvertiseしているか |
| Authorization server | client credentials grant、JWT assertion、secret rotationに対応するか |
| SDK | token storage、refresh、失敗時のcallback、現行extension versionは何か |
| 運用 | 停止、rotation、監査、rollback、incident対応があるか |
よくある失敗の切り分け
| 症状 | 最初に確認するもの | 避けたい対応 |
|---|---|---|
| user loginを要求される | 通常flowとextensionの選択、client/server support | ユーザーcredentialをCIへコピーする |
| extensionが無視される | per-request capabilities、識別子、clientの対応状況 | serverが自動で認識すると決めつける |
| token取得は成功するがtoolが403 | 対象scope、resource、serverのclaims検証 | 全scopeを付与して通す |
| expiry後にjobが失敗する | refresh実装、clock、token storage | 期限切れtokenを無限retryする |
| client secretがログに出る | debug、CI artifact、error report、環境変数の扱い | ログを公開して原因調査する |
| JWT assertionが拒否される | 公開鍵、issuer、subject、audience、expiry、algorithm | 署名検証を無効化する |
導入前の最小チェックリスト
- ユーザーの同意が必要な処理ではなく、service identityで実行してよい仕事か確認した
- clientとserverがClient Credentials extensionをopt-inで対応しているか確認した
- JWT assertionとclient secretを比較し、secretを使うなら保管・rotation・漏えい対応を決めた
- client capability、token取得、Authorization header、refreshを別々にテストした
- server側のsignature、claims、resource、scope検証とtool allowlistを確認した
- read-only、sandbox、短いjob、連続失敗stopから始める計画にした
- CI/CDやdaemonのログにsecret・private key・token実値が残らないことを確認した
- client matrix、SDK、authorization server、MCP serverの対応日とversionを記録した
MCP Client CredentialsのFAQ
MCP Client Credentialsは何のための拡張ですか？
ユーザーのbrowser loginやinteractive consentがない状態で、サービス自身のclient identityを使ってMCP serverへ接続するためのopt-in OAuth拡張です。CI/CD、background service、server-to-server、daemonが候補です。
ユーザーがいる処理でもClient Credentialsを使えますか？
ユーザーが明示的に自分のデータへのアクセスを承認すべき処理では、通常のMCP Authorization flowを候補にします。Client Credentialsはサービスidentityの権限で動くため、ユーザー同意の代替として使わないでください。
JWT assertionとclient secretはどちらが安全ですか？
公式ページではJWT Bearer Assertionsが推奨形式として示されていますが、鍵管理や接続先の対応が必要です。client secretを使う場合は長期credentialの漏えいを前提に、secret manager、最小scope、rotation、ログ分離を設計します。
Client Credentialsならtoken refreshは不要ですか？
不要とは限りません。公式extensionページではclient credentials tokenは短い寿命になり得るため、expiry前に新しいtokenを取得するrefresh logicが必要と説明されています。
MCP clientがextensionを知っていれば使えますか？
使えるとは限りません。extensionはopt-inで、clientごとのsupportが異なります。capability宣言、token取得、refresh、server側のsignature・claims・scope検証を確認してください。
Client Credentialsでdeployを自動承認できますか？
認証方式はdeployの承認判断を代替しません。対象環境、差分、branch、review、rollback、停止条件を別に設計し、必要ならwrite scopeやdeploy toolを与えない構成から始めます。
まとめ：ユーザー不在の認証ほど、identityと権限を狭くする
MCP OAuth Client Credentials extensionは、ユーザーのconsentを省くための万能な近道ではなく、service identityで動く自動化向けのopt-in拡張です。CI/CDやdaemonへ組み込むなら、client capability、JWT assertionまたはsecret、token取得・refresh、Authorization header、server側のsignature・claims・scope検証を分けます。read-only・sandbox・短いjob・停止条件から小さく始め、client matrixと接続先の対応を確認してから本番のwrite操作へ進めてください。