Cloudflareが、self-managed OAuth をすべての開発者に開放しました。
これ、地味に見えてかなり大きなニュースです。というのも、OAuthは「外部アプリに、どこまで何を許可するか」を安全に扱うための仕組みで、SaaS連携や社内ツール、いま流行りのagentic toolまで、あちこちで土台になっているからです。
Cloudflareは自社のAPIを使って自動化やCI/CD、各種連携を作れる強いプラットフォームですが、これまでは第三者向けのOAuthは一部の手動オンボーディング済み統合に限られていました。
つまり、誰でも自由に「Cloudflare用のOAuthアプリ」を作れる状態ではなかったわけです。
その制限が外れた。ここが本題です。
記事の芯はわりとはっきりしています。
Cloudflareは20%のWebを支えている、と自分たちで書いていますが、当然それだけで完結する世界ではありません。開発者は他社のサービス、ツール、監視、CI/CD、認証、データベースなど、いろんなものを組み合わせて使います。
そこで重要なのがOAuthです。
OAuthは、ざっくり言うと「パスワードを渡さずに、必要な権限だけをアプリに渡す仕組み」です。
たとえば「DNSの編集だけ許可する」「このアカウントのこの範囲だけ見せる」といったことができます。API tokenでも似たことはできますが、記事が指摘している通り、委任されたアクセスの形にはOAuthのほうが自然です。
個人的にも、ここはかなり納得感があります。API tokenは便利だけれど、長く使うほど“管理が雑になりやすい道具”なんですよね。
CloudflareがOAuthを広く開いたのは、SaaS連携だけでなく、内部開発プラットフォームやagentic toolの需要が増えたからだと説明しています。
つまり、「人が手で触る前提」だけではなく、「ツールがツールを動かす前提」の世界に合わせた、ということです。
CloudflareはもともとOAuthを使っていました。Wranglerを使ったことがある人や、PlanetScaleのようなパートナー連携を使った人は、すでにOAuthの恩恵を受けていたそうです。
ただし、それは一部の手動で審査・導入された統合だけ。
広く開放された機能ではありませんでした。
その結果、開発者が自前の統合を作るときは、どうしてもAPI tokenに寄りがちだった。
でもAPI tokenは、用途によっては扱いづらい。
取り消しのしやすさ、利用者への説明のわかりやすさ、権限の範囲の見えやすさ。こうした点でOAuthに負けます。
記事では、過去1年ほどで早期パートナーを増やしながら、同時に同意画面、失効、セキュリティモデルを磨いてきたと書いています。
派手な機能公開の前に、ちゃんと地味な足場を作っていたわけです。こういう話は地味ですが、実はとても重要です。セキュリティ系の機能で「あとから整えます」はだいたい危ないので。
今回の self-managed OAuth では、開発者が自分でOAuthアプリを作り、顧客がそのアプリにスコープ付きのアクセスを直接許可できるようになりました。
スコープとは、許可の範囲のことです。「読み取りだけ」「特定機能だけ」といった粒度で権限を切れます。
これで何が嬉しいかというと、アプリを使う側にとっては、
という利点があります。
Cloudflare側にとっても、これは単に「外部連携が増える」以上の意味があります。
アプリが増えれば、CloudflareのAPIを中心にしたエコシステムが育つ。
こういうプラットフォーム戦略は、機能そのものよりも“周辺で何が作れるか”が勝負になるので、OAuth解放はかなり筋がいいと思います。
ここからが記事の面白いところです。
OAuthを全員に開放するには、見た目の機能追加だけでは足りません。むしろ本体は裏側です。
Cloudflareは以前、HydraというオープンソースのOAuthエンジンを使っていました。
HydraはOAuthを動かすための中核ソフトウェア、つまり「認可の心臓部」みたいなものです。便利だけれど、利用規模が大きくなると、そのままでは足りなくなる。
今回のアップグレードはかなり大掛かりでした。
しかも、いきなり大幅更新ではなく、まず1.X系の最新へ、そのあと2.Xへ、という順番で進めています。こういう慎重さは、実運用ではかなり正しいと思います。派手さはないけれど、障害の確率をちゃんと下げている。
最初の1.Xアップグレード自体は順調でした。
しかし、Hydraのデータベース移行では、なかなか嫌な性質があったようです。
たとえば、インデックス作成が排他ロックを取ってしまい、重要なテーブルでアクティブなユーザー操作を止める可能性があった。
排他ロックは、簡単に言えば「そのテーブルを他が触れないように閉め切る」ことです。大規模サービスでは、これが本当に厄介です。
Cloudflareはこれを避けるために、SQL migrationを書き直し、CREATE INDEX CONCURRENTLY のような、止めにくい方法を使うようにしました。
さらに、HydraのSDKが SELECT * を使っていたせいで、スキーマ変更時にデシリアライズ問題が出たので、明示的に列を選ぶようにしたカスタム版Hydraまで作っています。
ここ、かなり実装力が高いです。運用の都合に合わせて中身を変えているので、単なる導入ではなく“制御”している感じがします。
1.Xへの切り替え後には、refresh tokenのエラー増加が見つかりました。
refresh tokenは、アクセスを更新するためのtokenです。長くログイン状態を維持するために使われます。
新しいHydraでは、refresh tokenが再利用されると、その一連のtokenのつながり全体を無効化する、より厳しい挙動になっていたそうです。
これがWranglerやMCP clientのような高頻度通信のクライアントには相性が悪かった。
ちょっとした再試行が、セッション全体を吹き飛ばしかねないからです。
CloudflareはWorker側でrefresh token coalescingという工夫を入れ、短時間だけリクエストをまとめて、重複再試行をHydraに届く前にさばくようにしました。
2.Xではさらに、refresh tokenを一定期間だけ再試行できるgrace periodが用意され、問題の根本が解決できる見込みになったとのことです。
本丸の2.Xアップグレードは、いわゆるblue-green strategyで進めました。
これは、新しい環境を別に用意して準備し、最後に切り替える方法です。障害を減らしやすい一方、データの扱いが難しい。
Cloudflareは単純に「切り替えれば終わり」ではなく、かなり細かい作業をしています。
まず、アップグレード中に失われる可能性があるrevocation、つまり「このアプリの許可を取り消す操作」を、Cloudflare Queuesで記録してあとから再生できるようにしました。
これが重要なのは、取り消しが失われると、ユーザーが明示的に止めたアプリのアクセスが復活してしまうからです。これはかなり怖い。
さらに、
までやっています。
このあたりは、クラウド事業者らしいというか、単なるプロダクトチームの仕事というよりインフラ事業者の作業です。
「OAuth機能を追加しました」ではなく、「そのために基盤を三時間かけて移した」と言っているわけで、スケールの感覚が違います。
2.Xの移行は、本番でおよそ3時間かかったとあります。
かなり長いです。人によっては「そんなにかかるのか」と思うはずですが、この規模ならむしろ現実的でしょう。
切り替え後、今度は別の問題が発生しました。
authorization service 側のデータクリーンアップジョブが、OAuth policy data をやや攻撃的に消しすぎていたのです。
調べると、Hydraの移行の一部で有効なOAuth sessionの状態が壊れ、それを無効と判定してしまっていたらしい。結果として、Hydraと認可サービスの間で状態が食い違い、403エラーが増えました。
403は「アクセス禁止」です。
つまり、正しいはずの利用者まで弾かれていた。
Cloudflareはデータの復元を行い、今後は静的なpolicy dataへの依存を減らす改善にも着手したとしています。
このあたり、派手な成功談だけで終わらせず、ちゃんと失敗も書いているのが好感です。現場はだいたいこういう小さなズレとの戦いなんですよね。
アップグレード後のメトリクスはわりと印象的です。
データベース移行では、
132.5M行を更新し、114.7M行を挿入し、136.97GBのtemp bytesを使い、22.2k回のtransaction commitがあったそうです。
数字だけ見ると完全に“巨大工事”です。
Hydraの性能は、平均で次のように改善しました。
P95は「遅いほうから数えて95%のリクエストがこの時間以内」という指標です。
つまり体感に近い遅さの改善です。185msから101msは、かなり効いている。
メモリやCPUも減っていて、これは素直にうれしい結果だと思います。大規模システムのアップグレードは、互換性を保つだけで精一杯になりがちですが、性能まで上がっているのは強いです。
個人的には、ここがいちばん面白いです。
Cloudflareは「OAuthを全員に開放しました」と言っていますが、実際にはその背後で、プラットフォームとしての成熟を証明しているんですよね。
OAuthを広く開くには、
という条件が必要です。
つまり、このリリースは単なる機能公開ではなく、Cloudflareが外部アプリの土台として本気で使える段階に入ったという宣言に近いと思います。
これからSaaS連携や社内ツール、AIエージェントがCloudflareのAPIをより自然に扱えるようになるはずです。
そうなると、Cloudflareはネットワークの会社というより、「ネットワークを使うアプリのプラットフォーム」としての顔をもっと強めていくのではないでしょうか。
参考: Unlocking the Cloudflare app ecosystem with OAuth for all
