Claude Media
ClaudeにOAuth実装を任せた公開実例 — Cloudflareのコミット履歴を読む
Claude CodeMCPClaude連携解説

ClaudeにOAuth実装を任せた公開実例 — Cloudflareのコミット履歴を読む

CloudflareのOAuth認可ライブラリはClaudeへの1プロンプトから生まれ、275件のコミットがそのまま公開されています。何を頼み、どこを人間が直したかを追います。

読了目安 約10分

CloudflareのOAuth認可ライブラリ@cloudflare/workers-oauth-providerは、最初の1行までClaudeへのプロンプトから生まれました。開発者のKenton Varda氏(Cloudflareのエンジニア)は、コミット履歴をそのまま公開に残しています。どの指示でClaudeが何を書き、どこで人間が手を入れたかを誰でも追える形です。HTTP APIとリモートMCPサーバーにOAuth 2.1の認可を追加するために作られたこのライブラリを手がかりに、Claudeにセキュリティコードを書かせる実務を読み解きます。

workers-oauth-providerとは — Cloudflare製のMCP認可ライブラリ

@cloudflare/workers-oauth-providerは、Cloudflare Workers上でOAuth 2.1の認可サーバーを実装するnpmパッケージです。READMEによれば、HTTP APIとリモートMCPサーバーの両方にOAuth 2.1の認可を追加する用途で作られています。GitHub上でスター1.9k、フォーク134件を集め、コミット数は275件に達しています。

このライブラリが独自なのは機能面ではなく、生まれ方が記録として残っている点です。READMEとは別にHISTORY.mdというファイルがあり、Kenton氏自身による経緯がそのまま書かれています。「このライブラリ(スキーマのドキュメントも含む)は、大部分をAnthropicのAIモデルであるClaudeの助けを借りて書いた」という一文から始まります。275件のコミットメッセージには、「Ask Claude to〜」という書き出しが繰り返し登場します。何を頼み、Claudeが何を返し、どこを人力で直したかが、コミットログという形でそのまま公開されている実例です。Cloudflare MCPサーバーの一覧のようにClaudeからMCPサーバーを操作する場面だけでなく、リモートMCPサーバーの認可を実装するライブラリの側にもClaudeが関わっています。

最初のプロンプトは何を要求していたか

最初のコミットは2025年2月27日、コミットメッセージは「Have Claude write an OAuth provider implementation.」の一文です。本文には実際にClaudeへ送った依頼文がそのまま残されています。

要求は抽象的ではありませんでした。Cloudflare Workers上で動くTypeScriptライブラリという条件に加え、次のような実装上の制約を最初から指定しています。

  • OAuthProviderをexport defaultし、apiRoute・apiHandler・defaultHandler・authorizeEndpoint・tokenEndpoint・clientRegistrationEndpointを設定で受け取る
  • ストレージにはWorkers KVの名前空間OAUTH_KVを使う
  • トークンの有効期限はKVのTTL機能で実装する
  • トークン文字列そのものは保存せず、SHA-256でハッシュ化した「トークンID」だけを保存する
  • クライアントはclient_secretで認証する(Webアプリ想定で、secretを安全に保持できる前提)

最後の一文は「Can you please write this library?」でした。ここから275件のコミットを経て、現在npmで配布されているライブラリまで育っています。

チャットからClaude Codeへ、開発の流れ

初回プロンプトの翌日、コミットメッセージは「Asked Claude to convert to WebCrypto.」と続きます。Node.jsのcryptoモジュールを使っていた実装を、Cloudflare Workersで動くWebCrypto APIへ書き換えさせた指示です。同じ日には「Ask Claude to hash the auth code and client secret as well.」というコミットもあります。認可コードとクライアントシークレットもハッシュ化する、初回プロンプトになかった要件です。開発が進む中で追加指示を出していった跡がここに残っています。

3月4日の「Ask Claude to implement PKCE support (for OAuth 2.1).」というコミットには注記が付いています。「この時点でチャットセッションからClaude Codeの利用に切り替えた」という一文です。OAuth 2.0の実装からOAuth 2.1への移行と、PKCE(Proof Key for Code Exchange、認可コード横取り対策)の実装が境目でした。この頃にツールをClaude Codeへ移していたことが、コミットメッセージから読み取れます。

3月16日には「Initially publishing it as "restricted"」というコミットでnpmに初めて公開されました。その後、OAuthAuthorizationServerによる複数リソース対応、Client ID Metadata Documents(CIMD)、RFC 9207準拠の発行者識別など、MCP認可仕様2026-07-28版に対応した機能まで積み重ねています。

Claudeが手こずった場面

コミット履歴には、Claudeが一発で正解を出せなかった場面もそのまま残っています。代表的なのが構文を壊したケースです。Kenton氏は「export class OAuthProvider {の行がファイルの先頭に移動してしまい、パースできなくなった」とClaudeに伝えました。Claudeの最初の対応はさらにコードを混乱させるものだったため、氏は「この編集は状況を悪化させた。戻ってやり直そう」と、直すべき箇所をピンポイントで指定し直しています。2回目でClaudeは問題を修正しましたが、頼んでいない箇所の並び替えも一緒に行い、その過程で氏自身が気づいていなかった別のバグ(getClient()のprivate指定ミス)も直していました。

もう1件は、Claudeが最後まで直せなかったケースです。「Claudeは前のコミットにバグを残していた。何度も直すよう頼んだが、同じ間違いを繰り返した」というコミットメッセージがあり、最終的には「この変更は人間が手で書いた」と明記されています。

Kenton氏はHISTORY.mdで、この開発がvibe codingではないと明言しています。「すべての行を、そのRFCの経験を持つセキュリティ専門家がRFCと照合しながら徹底的にレビューした」という一文です。差分を読まずにAIへ委ねるvibe codingの定義とは対照的に、Claudeへの依頼と人間によるレビュー・修正を繰り返すサイクルが、275件のコミットという形で残っています。

いまはMCPサーバーの認可をどう実装しているか

現在のライブラリの使い方は、OAuthProviderをexport defaultするという最初のプロンプトの構造をほぼそのまま引き継いでいます。KVネームスペースOAUTH_KVをバインドしたうえで、次のようにインストールして設定します。

npm install @cloudflare/workers-oauth-provider
export default new OAuthProvider<Env>({
  apiRoute: '/mcp',
  apiHandler: McpApiHandler,
  defaultHandler,
  authorizeEndpoint: '/authorize',
  tokenEndpoint: '/oauth/token',
  scopesSupported: ['mcp:read'],
  resourceMetadata: {
    resource: 'https://mcp.example.com/mcp',
    authorization_servers: ['https://mcp.example.com'],
    scopes_supported: ['mcp:read'],
    resource_name: 'Example MCP server',
  },
  clientIdMetadataDocumentEnabled: true,
  clientRegistrationEndpoint: '/oauth/register',
});

apiRouteで保護したいパスを指定すると、そこへ届くリクエストのBearerトークンをライブラリ側が検証します。有効な場合だけapiHandlerへ渡す仕組みです。認可されていないリクエストはすべてdefaultHandlerに回り、アプリケーション側が実装する/authorizeエンドポイントがユーザー認証と同意を担当します。ライブラリ自身はIDプロバイダーではないため、誰がログインしているかの判定は呼び出し側の責任です。

MCPクライアントからの認可フローは、リモートMCPのOAuth認証で扱った401起点の発見フローと同じ形をとります。トークンなしのリクエストには401が返ります。そこから.well-known/oauth-protected-resourceでリソースメタデータを、.well-known/oauth-authorization-serverで認可サーバーメタデータを取得し、クライアントは認可・トークン交換先を見つけます。パブリッククライアントにはPKCE(S256)が必須です。Dynamic Client Registration(DCR)はMCP 2026-07-28仕様で非推奨となり、Client ID Metadata Documents(CIMD)が優先経路になりました。アクセストークン・リフレッシュトークン・クライアントシークレットはハッシュ化してのみ保存され、認可時に渡すpropsはAES-GCMで暗号化されます。人間不在の認証まで踏み込む拡張はMCPのOAuth Client Credentials拡張側の話題です。

Claudeにどこまで実装を任せられるか

この実例が示すのは「Claudeに書かせられるか」ではなく、どの工程を任せ、どこを人間が最後まで見るかという切り分けです。

工程Claudeに任せた範囲人間が最後まで担った範囲
初期実装Claudeに任せた範囲要件を明示したプロンプト1本で骨格を生成人間が最後まで担った範囲要件そのものの設計(KVスキーマ・ハッシュ化方針)
機能追加Claudeに任せた範囲PKCE・WebCrypto化・ハッシュ化などを個別に依頼人間が最後まで担った範囲各追加が既存仕様と矛盾しないかの確認
バグ修正Claudeに任せた範囲再現手順を伝えて再依頼人間が最後まで担った範囲直らないときの見切りと手動修正の判断
最終レビューClaudeに任せた範囲—人間が最後まで担った範囲RFCとの逐条照合、セキュリティ専門家によるレビュー

Claudeが「認可コードをどう保存するか」を自分で決めたわけではない点も、この表から読み取れます。SHA-256でのハッシュ化、KVのTTLでの期限管理といった設計判断は最初のプロンプトに書かれていました。Claudeが担ったのは、その設計をコードに落とす作業と、追加要件を出されたときの実装です。vibe codingの記事では、認証・決済のように重要度の高い処理はvibe codingに向かないと述べています。このライブラリはその重要度の高い領域を、プロンプトでの要件明示と後段の専門家レビューを組み合わせて成立させた実例です。

まとめ

workers-oauth-providerは、HTTP APIとリモートMCPサーバーにOAuth 2.1の認可を追加するライブラリとして公開されています。同時に、コミット履歴を読めば「Claudeにどうプロンプトすればセキュリティコードが書けるのか」の実例集にもなっているのが特徴です。要件を最初にどこまで具体的に書くか、Claudeが手こずったときにどこで見切りをつけるか、レビューをどこに置くか。この3点は、MCPサーバーの認可を自分で実装しようとする開発者にとって、そのまま参考になる記録です。

この記事を共有:XはてブLinkedIn

関連する記事

Claude Code をもっと見る →