CloudflareがClaudeとともにOAuthを構築し、すべてのプロンプトを公開
(github.com/cloudflare)- Cloudflareが OAuth 2.1プロバイダーフレームワーク を Cloudflare Workers 向けの TypeScript ライブラリとして発表
- 実装の大部分は Anthropic の Claude LLM を使って作成 され、Cloudflare のセキュリティエンジニアが綿密にレビュー
- このライブラリは API エンドポイント向け認証の自動化 と トークン管理の自動処理 を提供
- 最新の OAuth 標準と PKCE、動的クライアント登録、スコープ設定などの主要機能をサポート
- 重要な区間ごとに エンドツーエンド暗号化 とシングルユースのリフレッシュトークンなど セキュリティ設計 を重視
Cloudflare Workers 向け OAuth 2.1 プロバイダーフレームワークの紹介と重要性
このオープンソースプロジェクトは、Cloudflare Workers 環境で OAuth 2.1 認証サーバーを容易に実装 できるよう設計された TypeScript ライブラリ。
同種の他プロジェクトと比べると、Cloudflare プラットフォームに特化した 拡張性とスムーズな統合、そして セキュリティ中心の設計 が大きな強み。
アルゴリズム、プロトコル標準準拠（RFC-8414、RFC-7591 など）、ライブラリ構造の明確さなどに重点が置かれている。
特に、トークンおよび主要なシークレット値のハッシュ化保存、props のエンドツーエンド暗号化など、安全性のために細部まで設計されている。
参考までに、ライブラリのコアコードとドキュメントの大半は Claude LLM の協力で作成されており、興味深い開発事例となっている。
主な機能と利点
- OAuthProvider で Worker コードをラップし、API エンドポイントに認証機能を自動付与
- トークン管理（生成、保存、検証、破棄など）を自動処理 するため、個別実装が不要
- 利用者は fetch ハンドラー内で、すでに 認証済みユーザー情報 をそのままパラメータとして受け取って活用可能
- ユーザー管理や認証、UI 実装方式に制限なし（開発者が望む構成やフレームワークを自由に選択可能）
- ライブラリのストレージには ハッシュ情報のみ保存 され、秘密鍵などシークレットそのものは保存されない
使い方の要点
- OAuthProvider インスタンスを Worker エントリーポイントとしてエクスポートし、fetch ハンドラーとして動作させられる
- apiRoute、apiHandler オプションで、認証が必要な API エンドポイントの範囲と実際のハンドラーをそれぞれ指定
- authorizeEndpoint、tokenEndpoint、clientRegistrationEndpoint など、標準 OAuth エンドポイントの各パスを定義可能
- 必要に応じて scope や public client registration などのポリシーを細かく設定可能
- defaultHandler により、API 以外のリクエストや認証失敗時のリクエストも柔軟に処理可能
ヘルパーオブジェクトと API
- fetch ハンドラー内で
env.OAUTH_PROVIDERを使い、OAuth 関連リクエストの解析、クライアント情報の取得、承認完了処理などに利用可能 - API リクエスト処理では、access token が有効な場合、認可済み状態のユーザーごとの props 情報 に
ctx.propsから直接アクセス可能 - クライアント登録、権限（authorization grant）一覧、特定ユーザーの grant 閲覧や破棄なども公式 API として提供
Token Exchange Callback
- トークン発行・更新時に、props の値を動的に更新 できるコールバック（tokenExchangeCallback）をサポート
- OAuth クライアントと連携した追加のトークン交換（upstream token exchange）など、複雑なシナリオにも対応可能
- コールバックでは accessTokenProps、newProps、accessTokenTTL などを返し、カスタム動作を実装可能
- accessTokenTTL のカスタマイズにより、上位 OAuth システムとトークン失効タイミングを合わせられる
- props には機密情報を含められるため、この値全体はエンドツーエンドで暗号化されて保存される
カスタムエラー応答
- onError オプションを使い、エラー発生時に Notification の送信やカスタムロギングなどの外部対応が可能
- 返す Response を直接定義すれば、OAuthProvider がユーザーに返すエラー応答を任意の形式で上書き可能
セキュリティに関する詳細設計
エンドツーエンド暗号化
- トークン関連データやシークレットはハッシュのみ保存し、grant props 情報はトークン自体で暗号化して保存 することで、漏えい事故への耐性を高めている
- userId、metadata などは監査（audit）や破棄記録の用途のため暗号化せず、必要に応じて開発者が追加暗号化を適用可能
シングルユース・リフレッシュトークン設計
- OAuth 2.1 の要件である「クライアントバインディングまたはシングルユース」の条件に対し、このライブラリは 最大 2 個の並列リフレッシュトークンを許容 する折衷設計を採用
- これにより、ネットワーク障害などで新しいトークンの保存に失敗しても、以前のトークンをもう一度使える安全策を提供
Claude ベースの開発プロセス
- 本ライブラリと多数のドキュメントは Anthropic Claude LLM を活用して初稿が作成され、Cloudflare のエンジニアが RFC とセキュリティ基準に沿って綿密にレビュー
- 当初は AI コード生成に懐疑的だったが、実際の品質と生産性向上の体験を通じて見方が変化
- 開発フロー、Claude へのプロンプト、コード改善の過程は Git のコミット履歴ですべて透明に公開されている
その他
- Workers KV 名前空間（OAUTH_KV）のバインディング設定が必須、
storage-schema.mdを参照 - 全 API とヘルパーは
OAuthHelpersインターフェース定義を参照 - ライブラリは現在 ベータ/プレリリース段階 であり、今後 API が変更される可能性あり
1件のコメント
Hacker Newsの意見
READMEからの抜粋を紹介。このライブラリ（およびスキーマ文書）は、主にAnthropicのAIモデルClaudeの助けを借りて書かれた。Cloudflareのエンジニアが徹底的にレビューし、セキュリティと標準準拠に注意を払った。初期成果物にも多くの改善が加えられ、主にClaudeに追加のプロンプトを与え、その結果を反復的にレビューしながら進めた。コミット履歴では、Claudeにどうプロンプトしたか、どんなコードが出てきたかを実際に直接確認できる。最初は「LLMに認証ライブラリを書かせるべきではない」という伝統的な懐疑的立場だった。2025年1月の時点では私自身もAIに非常に懐疑的で、LLMは単なる「派手なMarkov連鎖生成器」にすぎず、斬新さや実際のコードを生み出せないと思っていた。プロジェクトは面白半分で始めたが、予想以上にまともなコードが出てきて衝撃を受けた。完璧ではなかったが、AIに修正を依頼すればきちんと直してくれた。1行1行を各種RFCと照らし合わせ、セキュリティ専門家と一緒にレビューした。自分の懐疑論を検証しようとしたが、むしろ自分が間違っていたことを証明する結果になった。コミット履歴、とくに初期コミットをぜひ見れば、この過程を確認できる
熟練したエンジニアが適切にプロンプトしたとき、LLMがこの程度のコードを十分に生成できるだろうとは思う。OAuthは新しい技術ではなく、すでに非常に多くのオープンソース例や多様な言語での実装ケースが学習データとして使われていたはずだ。ただ、LLMがまったく新しい研究、材料科学、経済、発明などに革新的に貢献するという主張には、今でも懐疑的だ。「リアルタイムで学ぶ能力」が本当に必要な領域だが、現存のLLMは、すでに知っている古い情報に基づいてしか能力を示してこなかった。意味のある成果はたいてい、非常に限定された環境での cherry-pick 事例にすぎない。熟練エンジニアがいれば、過去データをもとに新しいコード生成が可能なのは当然だと思うが、LLM導入がもたらす環境的・社会的負担が実際の効率性に比べて過大ではないかという疑問は依然としてある
「私は2025年1月まで（@kentonv）と同じ考えを持っていた」という表現に混乱した。kentonvは別ユーザーだからだ。これは本人の別アカウントなのか、それとも誤字や誤解なのか気になった。編集: 記事の大部分がREADMEの引用だと確認した。> と * 記号を使って引用を明確にしていれば、混乱はもっと少なかったと思う。kentonvプロフィールへのリンクを添付
「LLMを派手なMarkov連鎖生成器だと思っていた」と「AIがかなりまともなコードを作って驚いた」という2つの意見は、互いに矛盾しない。LLMは非常に有用だと感じるが、それでも本質的にはパターン生成器に近い。重要なのは、その程度で十分であり、人間もまた大きくは違わない構造かもしれないということだ
最近は pro-AI というより、より懐疑的な立場だが、それでもワークフローにAIを導入しようと試し続けている。実際には説明するほうが難しくて、ただ自分でやるほうが簡単だと感じる。大して楽しくもないが、これが「未来」の道具なのだから習得するのが賢明だと思う。まだ本当のAIツーリングはごく初期段階だと見ている。今後、面白いUXの事例が出てくることに引き続き関心がある
初期にClaudeがどうプロンプトされ、実際のコードをどう生成したかについて、コミット履歴を直接参照するよう案内。最初のコミットページへの直リンクを提供。明確で具体的な指示が多く、サンプルコミット1、サンプルコミット2なども見る価値がある
Cloudflare workers-oauth-provider のコミットのうち、問題のコミットからの抜粋。Claudeが前のコミットでバグを出し、何度もプロンプトで修正しようとしたが失敗し続けた。結局、人間が直接修正し、READMEにOAuth 2.1仕様上の問題まで文書化した。こうした経験には、私個人としてもAI活用で非常に共感する。半分まではうまくいくのに、残りで苦戦する様子をよく見る
AIは途中まではうまくやるが、いったんミスするとその後が全部だめになる点に注目している。ミスを発見したら、ただちに会話の最初からプロンプトを書き直してやり直すべきだ。いちど間違えた後は、どれだけ軌道修正しようとしても結果がずっとおかしい。だから正しい開始メッセージにすべてを明確に盛り込み、最初から作り直さないと同じミスを繰り返さない
こうした問題を和らげるには、テストや明確な仕様（spec）を用意してAIに解かせるのが有効だ。数か月前までは、AIがこの種の仕様パズルを解くのに時間がかかり、結果物の品質も素早い回答より低かった。だが最近はモデル性能がかなり向上し、この種の作業はかなり面白くなってきていて、仕様化できる場合の活用度が上がっている。個人的には sonnet 3.7 は 3.5 より大きな進歩を見せ、Gemini 2.5 Pro はさらに印象的だった。sonnet 4 はミスが少ないが、それでもソフトウェアエンジニアリングの観点（要件整理、技術的解決策の探索、アーキテクチャ設計、ユーザーストーリーと仕様作成、コード作成）からAIを適切に導かないと良い結果は得られない。加えて、良い例をAIに追加で与えると効果は最大化される。最近 OpenAI Realtime API でアプリを作ったときも、最初は完全に失敗したが、文書2ページとデモプロジェクト1つをワークスペースに追加したら、すぐに望む結果が出た（私の場合はAPIを別の使い方をする必要があったのに、うまく合っていた）
コミットの163〜172行で言及されている内容の中に、明らかに事実と異なる主張や、A/S（認可サーバー）実装ごとに解釈が異なる主張を見つけた。Auth0の認可サーバーにはネットワーク条件を考慮した「leeway」設定があるが、もっと厳格な認可サーバーもある。各実装で細部設計が異なるため、標準（RFC）と公開オープンソースだけをもとにLLMが安全に実装できる確率は、結局のところ自作するのと同程度の人間の監修が必要だと思う
LLMベースのツールが本当に投入人員を節約してくれるのか、それとも生産性の錯覚を与えているだけなのかについて、長期的な研究結果が気になる
こうした経験から、AIツールは実際に理解しているのではなく、巨大なパターンデータ集合をもとに偶発的な（emergent）出力を作っているのだと見ている
AIコーディングの未来は、ソフトウェアエンジニアが消え、ビジネスマンがボタンを押せばすべて終わるという LinkedIn/X 的なファンタジーではなく、熟練エンジニアがAIでコードの一部を作り、それを綿密にレビューし、テストする方向だろう。本当に重要な問いは、「kentonvはAIなしで1人でこのライブラリをもっと速く作れただろうか？」という点だ
AIと一緒にライブラリを作るのに数日かかった。手で自分で作るなら数週間、場合によっては数か月かかっただろうと推測している。ただし、ここでは非常に理想的なケースだ。明確な標準、明確なAPI仕様、そしてすでによく知られたプラットフォームという条件があったから可能だった。AIで Workers Runtime 自体を変えようとしたときは、時間短縮効果はあまりなかった。しかし、自分が慣れていない他人のコードベースでは、AIは本当に大きな助けになる。今では見知らぬ複雑なコード探索にも入りやすくなり、以前なら避けていたようなものでも、自分に必要な変更を簡単に加えられるようになった
AIなしで1人で作ったほうが速かったかという問いには、間違いなくノーだと思う。今あるツールと、改善し続けている活用ノウハウを見れば、今後3〜6か月以内にはAIで新しい解決策を直接コーディングするほうがもっと速くなる見込みだ。ただし、よく文書化され、構造が明確で、速いフィードバックループ（良い lint / ユニットテスト）が備わったコードベース環境が重要だと思う。私たちはその方向に進んでいる
経験上、AIが一部コードを生成してくれても、それを綿密にレビューし、テストしなければならず、この過程はむしろ自分で直接コーディングするより <i>遅い</i>。だから現段階ではAIは大きな助けになっていない。下手な手伝いはいないほうがまし、ということわざの通り、今のAIは「悪い手伝い手」だ
「経験豊富なエンジニアがAIでコードの一部を作り、綿密にテストする構造」なら、結局20人の kentonv の代わりに2人いれば十分なのではないか、という疑問が湧く。残り18人のための仕事は今後も生まれ続けるのだろうか。著者の事例は技術的に難しいプロジェクトだが、地味な LoB（業務）アプリ開発では何が変わるのか気になる
経験豊富なエンジニアが綿密なレビューとテストだけをするなら、ジュニア開発者の役割をすべてAIに置き換えた場合、将来のシニア開発者はどこから生まれるのかと問いたい。単純な反復作業にもそれなりの価値があるという立場だ
こうした多様な論点や意見を見ること自体が興味深い。Cloudflareがインターネットセキュリティ分野のリーダーらしく、新しい「vibe coding」のやり方で世界をつなぐ試みを見せてくれたことに感謝したい。こうしたAIプロンプトやコードなどが、ほかの開発者にもプログラミング探求への意欲を高めてくれると感じた。vibe programming は私の憂うつを乗り越え、私が慣れたやり方でコーディングできるようにしてくれた、とても意味のある手段だ。この体験が他の人にも役立つことを願っている。現在の世代も未来の世代も、こうしたやり方を活用していくと期待している。ただし、このやり方が人のメンタルヘルスや心理的問題とも結びつきうる点は議論すべきだと思う。結局のところ、こうしたツールは人間の補助手段であることを念頭に、私たちが情熱をもって成長できるようどう活用するかを考えたい。オープンソース分野で、技術力だけでなく、論理と配慮あるプロジェクトアプローチを示す事例が多く出てくることを期待する。Cloudflareにもう一度賛辞を送りたい
代表的なプロンプトのやり取り例をまとめてある。プロンプト書き起こし例では、実際のコスト（合計 $6.45）まで公開している。関連コミット1、コミット2などの資料も案内している。AIワークフローについてのまともな体験談（とくに熟練者のもの）の情報が、ハイプに埋もれてあまりないのは驚きだ。todo list 以外に、実際のライブコーディング事例の情報が知りたい状況だ。antirez、tptacek の記事（antirezの事例、tptacekの記事）も参考になるだろう
私は「vibecoding」は結局生き残らないと思う。依然として優れたプログラマによる検証やバグ修正が必要で、AIが直せないバグもあった。結局こうしたツールは、その作業をすでによく理解している人が速度を上げるための補助ツールだ。本当に基礎的なホームページ程度なら別かもしれないが、そういうものを自動生成するツールは何年も前から存在している
vibecoding は今のところ stakes の低い作業に最適だ。GUI、CRUDアプリ、単発の実験など、力を持たない人たちに新しい力を与える部分で有用性が高い。今回の件は vibecoding ではなく、LLM-assisted coding だと思う
実際には、vibecoding という言葉が攻撃用の藁人形のように使われる傾向を感じる。たいてい、LLMに任せたコードを少しだけ直して使うのも vibe coding と見なしてよいのではないか？
OPがAI生成コードだけでなく、プロンプトまで公開してくれたことにとても感謝している。個人的にはLLMで非Web系コード（特に最近ではSAP ABAPをリバースエンジニアリングして、データをSnowflakeに合わせる .NET 実装）を開発しようとして、毎回「幻覚」問題に苦しんでいる。ほかの人たちは成功例が多いと言うので、自分のプロンプトだけが問題なのかと思っていたが、今回公開された事例を見ると、自分もそこまで遠くないと分かった。LLMが自分にうまく合わない理由は、作っている問題が少し珍しく新しいからだと判断している。GitHubに公開されたOAuthのケースのように、十分に学習されている対象でないとLLMはうまく追従できない
この種の反復的で、すでに何百回も実装されてきたコードは、AIに完璧に向いている。全体のコードは1200行程度で小規模だ。AIを使っても2日以上かかったというのは、むしろ意外だった
この数か月、CursorでClaudeを使って自分の greenfield プロジェクトを進めていて感じたのは、第一に、ものすごく生産性が上がったこと。第二に、以前より精神的にずっと疲れること。第三に、短期間のうちにもツールがかなり速く進化し始めており、上の2つの効果も増幅されていることだ
私の経験でも、ほかの開発者たちでもまったく同じだ。LLM assisted coding は実際に生産性向上に大きく役立つが、そのぶん消耗も大きい。むしろ不思議に感じるほどだ
「こんなに疲れる」という点について質問したい。私は従来方式より、自分のエージェント（Devstral）との「ペアプログラミング」的な形で使っていて、コード全体を逐一タイプするよりレビューのほうがずっと簡単だ。time wise の観点では大きな利点がある。vibe coding ではコードベースの文脈が失われ、後でレビューや参入障壁がはるかに高くなる。一方、ペアプログラミングでは文脈を積み上げながら進めるので、レビューがずっと速いと感じる
私はむしろ正反対だ。AIが些細なディテールを全部面倒見てくれるので、むしろ大きな安心感がある。アーキテクチャなど上位目標に集中できるようになって自由になった
Cloudflareのような会社で "Too Many Requests" エラーが出るのが、かなり愉快に感じられる