2026 年 4 月末、Zenn Trending に 「MCPサーバーを作りたくて OAuth 2.1 をちゃんと学んだ記録」 がランクインしました。MCP（Model Context Protocol）サーバーを 社外公開 / 顧客向けに提供 する案件が増えるにつれ、「認証どうしますか？」 がほぼ全相談で出てくる質問になっています。
弊社の受託では、過去 6 か月で 「自社の社内システムを MCP 化して顧客の AI エージェントから安全に呼ばせたい」 という案件が 4 件続きました。本記事では、自作 MCP サーバーを OAuth 2.1 で守る設計を、受託の現場目線で整理します。
なぜ MCP サーバーで OAuth 2.1 が事実上の標準になるのか
MCP サーバーの認証方式は仕様上はいくつか選べますが、受託で 顧客の本番環境に組み込む 前提だと OAuth 2.1 がほぼ唯一の選択肢になりつつあります。
| 認証方式 | 受託で使えるか | 理由 |
|---|---|---|
| API Key | △ | ローテーションと監査が弱い |
| Basic 認証 | ✕ | パスワード平文流通、論外 |
| mTLS | △ | 顧客環境にクライアント証明書配布が重い |
| OAuth 2.0 | ○ | 古い仕様で PKCE / Implicit が混乱 |
| OAuth 2.1 | ◎ | PKCE 必須化、Implicit 廃止で安全側に統一 |
| OIDC | ○ | OAuth 2.1 + ID トークンで認証も可 |
OAuth 2.1 は OAuth 2.0 のベストプラクティスを義務化 した仕様で、受託で公開する MCP サーバーには PKCE 必須 + Implicit Flow 廃止 という現代的な前提を当然視できる利点があります。
MCP × OAuth 2.1 の最小フロー
受託で公開する MCP サーバーへのアクセスフローの最小構成を示します。
[顧客側AIエージェント] [認可サーバー] [MCPサーバー]
↓ 1. 認可リクエスト + PKCE
────────────────────────────────→
↓ 2. ユーザ認証
↓ 3. 同意画面（スコープ表示）
←────────────────────────────────
↓ 4. 認可コード受領
↓ 5. トークンエンドポイント呼び出し（PKCE verifier）
────────────────────────────────→
↓ 6. アクセストークン発行
←────────────────────────────────
↓ 7. MCPツール呼び出し（Bearer）
──────────────────────────────────────────────────────────────→
↓ 8. トークン検証
↓ 9. スコープ確認
↓ 10. ツール実行
←──────────────────────────────────────────────────────────────ポイントは 「認可サーバー」と「MCP サーバー」を分離する設計です。受託では将来 MCP ツールが増減するため、認可サーバーを共通化しておくと 新規ツール追加のたびに認証実装をやり直さない 構造になります。
受託で押さえる “スコープ設計” のコツ
OAuth のスコープは MCP の ツール / リソース粒度 に直結します。受託で運用する標準的なスコープ設計を示します。
| スコープ命名 | 例 | 受託での使い分け |
|---|---|---|
mcp:tool:* | mcp:tool:db.query | 個別ツールへの細粒度許可 |
mcp:resource:* | mcp:resource:customer.read | リソース単位（CRUD と組み合わせ） |
mcp:scope:* | mcp:scope:read-only | プリセット（読み取りのみ等） |
mcp:tenant:* | mcp:tenant:acme-corp | マルチテナント分離 |
特に マルチテナント分離 (mcp:tenant:*) は、受託で複数顧客の MCP サーバーを 1 つのインフラで運用する場合の生命線です。トークンに tenant クレームを必須化し、MCP サーバー側でクレーム不整合のリクエストを即拒否 する実装にしておかないと、テナント境界を越えた事故になります。
これは 既存 API を MCP サーバー化する設計パターン で扱った “API → MCP の橋渡し” の 認証・認可レイヤー版 に当たります。
トークン寿命とリフレッシュ — 受託で運用しやすい設定
MCP サーバーは 長時間動作するエージェント から呼ばれるため、トークン寿命の設計が運用に直結します。
| トークン種別 | 寿命の目安 | 受託での運用設計 |
|---|---|---|
| アクセストークン | 5〜15 分 | エージェントは都度リフレッシュ前提 |
| リフレッシュトークン | 30〜90 日 | 利用ごとに rotation（reuse 検出で失効） |
| 同意の有効期限 | 1 年 | 年 1 回ユーザに再同意を促す |
| MCP セッション | アクセストークン同等 | セッション → リクエスト都度のステートレス |
Refresh Token Rotation は OAuth 2.1 のベストプラクティスとして強く推奨されており、受託で MCP サーバーを公開する案件では 必須実装として見積もりに含めるべきです。
運用上の “落とし穴” 5 選
実装現場で踏みやすい落とし穴を整理します。
| 落とし穴 | 何が起きるか | 対策 |
|---|---|---|
| 認可サーバーをアプリ内に同居 | 障害時に MCP もろとも停止 | 認可サーバーを別プロセス / 別サービスに分離 |
| アクセストークンに過剰なクレーム埋め込み | サイズ膨張で HTTP 426 や API GW 超過 | クレームは最小、JWKS で検証鍵だけ配布 |
| リフレッシュトークンの使い回し | 流出時の被害が拡大 | rotation + reuse detection 必須 |
| スコープを後から細粒化 | 既存連携が全壊 | 大粒度から始めて、*:read / *:write を後で分割 |
| ログにトークンが平文で残る | ログ流出時に致命傷 | OAuth ライブラリのロガーを上書き、構造化ログでマスク |
特に 「認可サーバーをアプリ内に同居」 は受託初期によく見るアンチパターンで、運用が始まってから分離するのは構造変更を伴うため、最初から別レイヤーに置くことを SOW で握っておくのが堅実です。
マルチテナント MCP サーバーの権限境界
受託で 複数顧客が同じ MCP インフラを共用 する設計では、OAuth スコープ + クレームベースの権限境界が生命線です。実装の最小構成：
// MCP サーバー側のミドルウェア（疑似コード）
async function authenticate(request) {
const token = extractBearer(request);
const claims = await verifyJWT(token, jwksUri);
// 1. スコープ確認
if (!claims.scope?.includes(`mcp:tool:${request.toolName}`)) {
throw new ForbiddenError('insufficient_scope');
}
// 2. テナント境界
if (claims.tenant !== request.tenantId) {
throw new ForbiddenError('tenant_mismatch');
}
// 3. 監査ログ（テナント / 呼び出し者 / ツール）
await auditLog({
tenant: claims.tenant,
sub: claims.sub,
tool: request.toolName,
timestamp: Date.now(),
});
return claims;
}ポイントは 3 段の確認（スコープ → テナント → 監査ログ） を必ずミドルウェアの最初に通すことです。1 つでも抜けるとテナント境界事故 / コンプライアンス事故になります。
これは AIエージェント本番DB削除ガードレール で扱った “破壊的操作のガードレール” の 認可レイヤー版 に当たります。AI エージェント時代は、「人だけでなくエージェントも誤ったテナントへ接続する可能性」を前提に、機械側で物理ブロックする設計が必須になっています。
受託パッケージの価格レンジ
弊社で「自作 MCP サーバーの OAuth 2.1 認証設計 + 実装」を受託メニューとして提供する際の価格レンジです。
| パッケージ | 期間 | 価格レンジ | 主成果物 |
|---|---|---|---|
| 設計レビューのみ | 1 週 | 30〜60 万円 | 認証設計書 + リスク評価 |
| 認証層実装（PKCE / JWT 検証） | 3〜5 週 | 200〜450 万円 | 認可サーバー + MCP 認証ミドルウェア |
| マルチテナント分離込み実装 | 6〜10 週 | 400〜900 万円 | 上記 + テナント境界 + 監査ログ統合 |
| 月次運用 + 監査対応 | 月額 | 15〜50 万円/月 | トークン運用 + 監査ログ確認 + 年次更新 |
「設計レビューのみ」でも引き受けるのは、受託で他社が実装した MCP サーバーの認証層が脆い、というケースが頻発するためです。実装に踏み込まず、SOW 段階で論点を整理するだけでもクライアントの意思決定が早くなります。
引き渡しチェックリスト — 受託でそのまま使える 12 項目
- OAuth 2.1（PKCE 必須）で認可フローが実装されている
- Implicit Flow / ROPC が一切残っていない
- 認可サーバーが MCP サーバーと別プロセス / 別サービス
- アクセストークンの寿命が 5〜15 分
- Refresh Token Rotation が有効、reuse 検出で即失効
- MCP ミドルウェアでスコープ → テナント → 監査の 3 段確認
- JWKS による公開鍵配布が稼働
- 監査ログがテナント別に分離保存
- OAuth ライブラリのロガーがトークンをマスク
- スコープ命名規則が文書化されている
- 既知の脆弱性（CSRF / open redirect 等）への対策が確認済み
- 年 1 のセキュリティレビュー予算が SOW に明記
まとめ — MCP の認証は “受託の信頼” を支える基礎工事
MCP サーバーは 「ツール → 顧客データ」 の最短経路にあるため、認証層の品質がそのまま 受託で構築するシステム全体の信頼性 に直結します。OAuth 2.1 + PKCE + Refresh Token Rotation + 監査ログ という現代的な構成を、最初から設計に組み込むのが受託側の責任範囲です。
弊社では、新規 MCP サーバー案件の立ち上げ時に 「認証設計 → 実装 → 運用設計」 を 3 ステップで一貫実施するパッケージを標準化しています。「MCP を社外公開したいが認証で詰まっている」「他社実装の MCP の認証層をレビューしてほしい」というご相談は お問い合わせフォーム からお気軽にどうぞ。
