Workers OAuth Provider が v1 — 認可サーバーと MCP サーバーを別 Worker に分けられるようになった

要約

Cloudflare は 2026-10-01、MCP サーバーの認証に使う Workers OAuth Provider を v1 にしました。

最大の変更は API の分割です。 1つの Worker が認可サーバー（authorization server）として動き、MCP サーバーはリソースサーバー（resource server）として別の Worker で動かせます。 トークン検証は Service Bindings 経由で行われ、公開インターネットを経由しません。

この分割が何を解くのかを説明します。

MCP サーバーを複数立てる状況は、すでに一般的です。 社内の文書検索用、チケット操作用、デプロイ操作用。それぞれ別の MCP サーバーとして立てるのが自然な構成です。 ところが従来は、認証の実装が各サーバーに入ることになり、問題が3つ出ました。

1つ目は、実装の重複です。 OAuth の処理を各サーバーが持つと、修正が必要になったとき全サーバーを直すことになります。認証は最も間違えたくない部分なので、重複は素直にリスクです。

2つ目は、トークンの管理が分散することです。 サーバーごとに独立した認可を行うと、ユーザーはサーバーごとにサインインします。 社内で5つの MCP サーバーを使うなら5回です。

3つ目は、統制の単位が揃わないことです。 認証が各サーバーに埋め込まれていると、「誰がどのサーバーへアクセスできるか」を一か所で見られません。

v1 の分割は、この3つに対応します。 認可を1つの Worker に集め、各 MCP サーバーはトークンを検証するだけにする。検証が Service Bindings 経由なので、公開インターネットを経由せず、レイテンシも低く抑えられます。

MCP 2026-07-28 の認可仕様に完全対応しました。 Client ID Metadata Documents と issuer 識別に対応し、動的クライアント登録（DCR）を使う旧クライアントとの後方互換も維持しています。新仕様へ上げても古いクライアントが切れないという点は、社内に複数のクライアントが混在する環境では重要です。

追加機能を整理します。

ステップアップ認可 — insufficientScope() で1行で実装できます。「通常の操作は通すが、破壊的な操作のときだけ追加の認可を求める」という設計が書けます。

リソースメタデータ — OAuthResourceServer が RFC 9728 の protected resource metadata を公開し、401 チャレンジで認可サーバーを指し示します。 クライアントが「どこで認可を取ればよいか」を自動で見つけられます。

複数 MCP サーバー — 1つの認可サーバーが複数の MCP サーバー向けトークンを発行でき、WAF とレート制限は MCP サーバーごとに独立して設定できます。

トークン管理 — refreshTokenIdleTTL によるスライディング有効期限（使われている間は延びる）、purgeExpiredData() による再開可能な KV クリーンアップ。

移行について。 0.x からの移行で必須の変更は resourceMetadata: { resource } の追加のみです。移行用の skill が同梱されており、コーディングエージェントに移行作業を任せられます。v0.x の廃止期限は本発表では示されていません。

何が変わったか

• API の分割: 認可サーバー（1つの Worker）とリソースサーバー（MCP サーバー、別 Worker）を分離
  • トークン検証は Service Bindings 経由で、公開インターネットを経由しない
• MCP 2026-07-28 の認可仕様に完全対応
  • Client ID Metadata Documents と issuer 識別に対応
  • 動的クライアント登録（DCR）を使う旧クライアントとの後方互換を維持
• ステップアップ認可: insufficientScope() で1行
• リソースメタデータ: OAuthResourceServer が RFC 9728 の protected resource metadata を公開し、401 チャレンジで認可サーバーを指す
• 複数 MCP サーバー: 1つの認可サーバーから複数サーバー向けトークンを発行。WAF とレート制限は MCP サーバーごとに独立設定
• トークン管理: refreshTokenIdleTTL（スライディング有効期限）、purgeExpiredData()（再開可能な KV クリーンアップ）
• 移行: 必須は resourceMetadata: { resource } の追加のみ。移行用 skill が同梱
• v0.x の廃止期限は示されていない

業務インパクト（一般企業向け）

MCP サーバーを社内で運用している組織には、構成を見直す理由になります。

まず確認すべきは、自社の MCP サーバーがいくつあるかです。

1つなら、v1 への移行は resourceMetadata の追加だけで、分割の恩恵はほぼありません。 移行する理由は MCP 2026-07-28 対応になります。急ぐ必要はなく、次の改修のついでで足ります。

2つ以上あるなら、分割の検討に値します。 とくに今後増える見込みがある場合です。認証を各サーバーに持たせる構成は、サーバー数に比例して保守コストが増えます。3つ目を立てる前に認可を1か所へ集めるのが、構成変更のコストが最も小さいタイミングです。

次に、MCP サーバー単位の WAF とレート制限について。これは実務で効きます。

MCP サーバーは、処理の重さが大きく違います。 文書検索は重く、設定の読み取りは軽い。同じレート制限を全部に当てると、重いサーバーに合わせて全体が厳しくなるか、軽いサーバーに合わせて重いサーバーが過負荷になります。

サーバー単位で分けられると、ここが解けます。 さらに、破壊的な操作を持つサーバー（デプロイ、削除）にだけ厳しい制限を当てるという設計もできます。権限で制御する層とは別に、流量で制御する層を持てるということです。

ステップアップ認可は、承認フローの設計に使えます。

エージェントが MCP 経由で社内システムを操作する構成では、「どこまで自動で許すか」が必ず問題になります。 全操作に認可を求めると使えず、全部自動だと怖い。

insufficientScope() が1行で書けるなら、「読み取りは通す、書き込みは追加認可」という線を実装で引けます。 これを運用ルールの文書で担保するのではなくコードで担保できるのが要点です。文書は守られませんが、実装は効きます。

移行作業について、1点注意を書きます。

「移行用 skill が同梱されており、エージェントに任せられる」という案内は便利ですが、認証の変更をエージェントに任せきりにするのは避けるべきです。 理由は、認証の不具合が「動かない」ではなく「動くが安全でない」という形で出ることがあるためです。動作確認で気づけません。

具体的には、移行後に次を人が確認すべきです。 未認証のリクエストが 401 で落ちること。 期限切れトークンが拒否されること。 別ユーザーのトークンで他人のリソースへアクセスできないこと。 エージェントに作業させるのは構いませんが、検証項目は人が決めて人が確認するという分担にすべきです。

最後に、v0.x の廃止期限が示されていないことについて。

期限が無いので急ぐ必要はありませんが、「期限が無いから放置する」は推奨しません。 認証ライブラリはセキュリティ修正が v1 系にだけ入る可能性が高く、その時点で急ぎの移行になります。余裕があるうちに移行しておくほうが、追い込まれてからやるより安全です。 必須の変更が1行である今が、最もコストが低い時期です。

副業・個人活用視点

個人で MCP サーバーを作っている人には、v1 の分割は「作り方の型」として参考になります。

個人で MCP サーバーを作るとき、認証は最も手を抜きやすい部分です。 自分だけが使うツールなら、認証なしか、固定トークンで済ませることが多いはずです。これは自分用なら問題ありませんが、他人に使わせる段になると作り直しになります。

v1 の構成（認可を分離し、各サーバーはトークン検証だけ）は、その作り直しを見越した設計です。 最初から認可を別 Worker に切り出しておけば、サーバーを増やすときに認証を書き直さずに済みます。 個人のプロジェクトでも、2つ目を作る可能性があるなら最初から分けておく価値があります。

配布を考えている場合、MCP 2026-07-28 への対応は実質必須になります。

MCP クライアント（Claude Code、各種エディタ、デスクトップアプリ）は、仕様の新しいバージョンへ順次移行します。 公開する MCP サーバーが古い仕様のままだと、クライアント側の更新で接続できなくなる可能性があります。後方互換が維持されている今のうちに新仕様へ上げるのが、トラブルを避ける順序です。

受託の文脈では、MCP サーバーの構築案件が出始めている前提で書きます。

「社内システムを Claude や Copilot から操作できるようにしたい」という相談は増えています。 技術的には MCP サーバーを立てる話ですが、顧客が本当に気にしているのは認証と権限です。 「誰がどこまで操作できるか」を説明できないと、情報セキュリティの審査を通りません。

ここで v1 の構成が提案材料になります。 認可を1か所に集め、サーバーごとに WAF とレート制限を分け、破壊的操作にはステップアップ認可を要求する。 この3点セットは、審査で聞かれる質問にそのまま答える形になっています。「権限管理はどうなっていますか」に対して構成図で答えられるかどうかは、案件の進み方を変えます。

見積もりの際に押さえておくべき点を2つ書きます。

1つ目。認可サーバーの分離は、サーバー1つの案件では過剰になります。 「将来増えるので分けておきます」と提案するのは構いませんが、増える見込みが無いなら工数の無駄です。顧客の計画を聞いてから決めるべきです。

2つ目。認証周りの検証工数を見積もりに入れること。 実装は skill で短縮できますが、検証は短縮できません。 未認証リクエストの拒否、期限切れトークン、他ユーザーのリソースへのアクセス。これらの確認に時間を取らない見積もりは、後で品質の問題になります。

学習の観点では、「認可サーバーとリソースサーバーの分離」という OAuth の基本構造を、実装を通して理解する機会になります。

OAuth を仕様書から学ぶのは骨が折れますが、「認可を出す側」と「それを検証する側」を別の Worker として書くと、構造が手で分かります。 insufficientScope() や RFC 9728 の protected resource metadata といった要素も、なぜその仕組みが必要なのかが実装の中で見えます。

とくに RFC 9728（protected resource metadata）の考え方は応用が利きます。 **「アクセスを拒否するときに、どこで認可を取ればよいかも併せて返す」**という設計です。エラーを返すだけでなく、次に取るべき行動を一緒に返す。 これは API 設計の一般的な作法として転用できます。エラーメッセージに「どうすればよいか」を含めるかどうかで、使う側の手間が大きく変わります。