公開日: 2026-06-24T06:00:00.000Z
著者: Sam Cabell, Mike Escalante, Adam Bouhmad, Nick Comer
所要時間: 6分読

概要

Cloudflareはウェブの20%を支えるサービスを提供していますが、それを単独で成し遂げているわけではありません。プラットフォーム上の開発者は他社のツールやサービスも多数利用します。Cloudflareはプラットフォーム用の豊富なAPIを提供しており、開発者は自動化、CI/CD、インテグレーションを作成してインフラの各要素をつなげられます。

今月初め、我々は「self-managed OAuth」を発表しました。これにより、顧客がCloudflare APIへの委譲アクセス用に自分自身でOAuthクライアントを作成・管理しやすくなります。

Cloudflare自体はOAuthの利用が初めてではありません。Wranglerを使ったことがある方や、PlanetScaleなどパートナーの統合を利用したことがある方は既にOAuthを使っています。しかし従来、サードパーティOAuthは手作業でオンボードした限定的な統合でしか利用できず、より広い開発者コミュニティには開放されていませんでした。その結果、独自の統合を構築する開発者はAPIトークンに頼らざるを得ず、これらは管理が難しく、多くの委譲アプリケーションのフローには適していませんでした。

過去1年で我々は初期パートナーのオンボーディングを進めると同時に、同意（consent）、無効化（revocation）、セキュリティモデルを改善してきました。しかし、Developer Platformの成長とエージェンティック（agentic）ツールが委譲アクセス需要を押し上げる中で、OAuthをすべての顧客に開放することがプラットフォーム成功の鍵であることが明白になりました。

self-managed OAuthにより、開発者は顧客がスコープ付きアクセスを直接付与する標準的なOAuthフローを提供できるようになりました。これにより、SaaS統合、内部デベロッパープラットフォーム、エージェンティックツールの構築が容易になり、ユーザーにはより明確な同意、簡単な取り消し、アプリケーションの権限に対するより良い制御が提供されます。

セキュアにエコシステムを拡大する

以前のOAuthソリューションは限定的なパートナーには十分でしたが、権限モデル、同意体験、潜在的な悪用ベクターの緩和策はまだ成熟していませんでした。今年初め、どのアプリがアクセスを要求しているのか、どの権限を受け取るのかをより明確にするために同意体験を更新しました。また、ダッシュボードに無効化機能を追加して開発者がどのアプリが自分のデータにアクセスできるかを簡単に制御できるようにし、OAuthフィッシング攻撃を防ぐためにアプリの所有権表示も強化しました。

すべての顧客にself-managed OAuthを開放するためには、基盤となるOAuthエンジンの大規模なアップグレードも必要でした。このプロセスは、ユーザーへの影響を最小限に抑えつつ、データの安定性とセキュリティを確保するために大量の計画を要しました。

OAuthエンジンのアップグレード計画

数年前、我々はHydraというオープンソースのOAuthエンジンを導入してCloudflare OAuthを駆動してきました。そのデプロイは、使用量が限られている時期には十分でしたが、Developer Platformの成長とエージェンティックなワークフローの一般化に伴い、新機能解放とパフォーマンス改善のために大規模なアップグレードが必要になりました。

アップグレード計画では、一度に大きく切り替えるのではなく、2つの小さな連続したアップグレードを行うことにしました。まず最新の1.Xリリースに移行して挙動やパフォーマンスの変化を評価し、その後2.Xへの移行を進めるというものです。

しかし、1.Xへのアップグレードでさえ顧客への影響を避けられないことが判明しました。Hydraのデータベースでは広範なスキーマ移行が必要で、具体的には：

• 重要テーブルに対し排他ロックを伴う形でインデックスを作成してしまい、アクティブユーザーが重要なOAuth操作を行えなくする可能性がある。
• 重要テーブルに列を追加し、別の列を新しいテーブルへ移動する必要がある。

さらに、当時使用していたHydraのバージョンにはSDKがSELECT *を実行する挙動があり、スキーマ変更時のデシリアライズ問題を引き起こすという癖がありました。

ユーザー影響を防ぐため、我々はSQLマイグレーションを書き直してCREATE INDEX CONCURRENTLYなどの機能を利用し、またSELECT *の代わりに明示的な列を選択するカスタム版Hydraを構築しました。

最新の1.Xアップグレードの計画が整った後、さらに大きな2.Xアップグレードの計画を策定する必要がありました。3つの選択肢を特定し、それぞれの利点と欠点を検討しました。

インプレースアップグレードは、メジャーバージョンの跳ね上げによるスキーマ変更量のため現実的ではありませんでした。我々はブルーグリーン戦略が有効と判断しましたが、新バージョンに切り替えるためにスイッチを切るだけでは不十分でした。マイグレーションと移行プロセスは数時間を要し、その間もシステムが正しく動作し続ける必要がありました。

最初のブルーグリーン案では、データベースへの書き込みを停止して新しい承認が発生しないようにする方法がありました。これにより移行中の承認は失われませんが、有効な資格情報を持っていない限り既存のOAuthアプリを誰も使用できなくなるという問題と、アップグレード中にユーザーがアプリのアクセスを取り消す必要があってもそれができないという大きな問題が残りました。

これらの課題に対処するため、書き込みを維持する方法を考案しました（ただしグリーンへ切り替えた際に一部の書き込みを失う可能性は受容）。まず新しいトークンの書き込み数を最小化する必要があり、運用上のレバーとしてトークンの有効期限を数時間に伸ばしました。これにより、アップグレード開始前に発行されたトークンはリフレッシュなしで継続利用できるようになります。

書き込み削減が解決した後、アップグレードウィンドウ中にユーザーが行った無効化（revocation）を失わない方法を考えました。そのため、Cloudflare Queues! を使ったキューシステムを構築し、無効化イベント発生時にその情報をキューへ書き込むようにしました。これにより、データベースをグリーンに切り替えた後にキューをドレインして、期間中に発生したすべての無効化イベントを再生（replay）できます。これを正しく扱わないと、ユーザーが取り消したはずのアプリに誤ってアクセス権が復元されてしまうため、非常に重要な対策でした。

アップグレードの実行

1.Xへのアップグレード

運用面では、最初の1.Xアップグレードは大きな問題なく完了しました。カスタムのデータベースマイグレーションは予想より速く実行され、ユーザーへの影響はありませんでした。古いバージョンは新しいバージョンが作成したトークンをインスペクトできなかったため、ハードカットオーバーが必要でした。

カットオーバー後、我々はこれまで見たことのないリフレッシュトークンエラーの増加を観測しました。これは新バージョンでのリフレッシュの無効化挙動が厳格になったためで、リフレッシュトークンが再利用されるとHydraはアクセス・リフレッシュトークンのチェーン全体を無効化してしまいます。

これはWranglerやMCPクライアントにとって問題でした。これらのクライアントは高いリクエストボリュームを持ち、単一の再利用されたリフレッシュトークンがセッション全体を無効化してしまうからです。これを緩和するため、OAuthトラフィックを適切な宛先にルーティングするWorkerにリフレッシュトークンのコアレッシング（coalescing）振る舞いを追加しました。これにより、Hydraに到達する前にリフレッシュリクエストを短時間キャッシュし、リトライを検出した場合は短絡して応答することでトークンの無効化を回避しました。

幸いにも、Hydraの2.Xバージョンには設定可能な“refresh token grace period”があり、これにより一定期間内のリフレッシュトークンの再試行を許容してチェーン全体を無効化しないようにできます。

2.Xへのアップグレード

ユーザーに数時間にわたる重大な影響を与えるわけにはいかないため、我々はブルーグリーン戦略を採用しました。高レベルでは、マイグレーションは本番データベースのコピー上で実行され、完了後に新しいHydraバージョンへ切り替えます。しかし実際には多数の作業が同時並行で必要でした：

• revocation replay capture queue を有効化する
• データベースを新しいターゲットへコピー・リストアする
• ターゲット側のデータクリーンアップ — 既存データが新バージョンで導入された制約に違反しており、マイグレーションが失敗する可能性があった
• Hydraサービスのカットオーバーと同時に、2つの追加の重要な内部システムの設定も切り替えてエラーを防ぐ
• カットオーバー後の監視と検証

低トラフィック時間を狙ってアップグレードウィンドウを選び、失われるトークン書き込みを最小化しました。タイムアウトチューニングを除けば、本番でのマイグレーションは順調に進み、実行時間は概ね約3時間でした。

マイグレーション完了後、我々は慎重にHydraサービスの新バージョンと2つの内部設定をロールアウトしてSDKを新バージョンに切り替えました。トラフィックを切り替えて間もなく、Hydraのconsent session APIに依存する認可サービスのデータクリーンアップジョブがOAuthポリシーデータの削除を過剰に行っていることを観測しました。

調査の結果、あるHydraマイグレーションに不具合があり、特定の有効なOAuthセッションの状態が破損してしまい、マイグレーションがそれらを無効とマークしていたことが判明しました。有効なセッションが破損したことでHydraと我々の認可サービスの間に不一致が生じ、403エラーの増加として現れました。

これを緩和するために、データの復元を行い、静的なポリシーデータへの依存を取り除くためのOAuth認可振る舞いの改善作業を開始しました。データクリーンアップ問題以外にも、特定クライアントの挙動に起因する小さな修正を短期間で適用しました。

Hydraバージョンアップが完了して以降、OAuthトラフィックは安定し、顧客に対するシステム性能と信頼性が向上しました。また、このアップグレードにより本番環境はステージングで既に検証済みだった新しいOAuth APIの基盤と一致し、6月3日のself-managed OAuthリリースへの道が開かれました。

パフォーマンス改善

大規模なアップグレードを完了した後は、その影響を示す広範な指標を確認するのが有益です。我々はデータベースマイグレーション中に追加のメトリクスを収集し、アップグレード完了後にかなりのパフォーマンス改善を観測しました。

データベースメトリクス（概数）

• Rows updated: 132.5M
• Rows inserted: 114.7M
• Temp bytes: 136.97GB
• Transaction commits: 22.2k

Hydraパフォーマンス（平均）

指標	Before	After	変化
API P95	185ms	101ms	-45%
RSS memory	888MB	763MB	-14%
Go heap alloc	449MB	271MB	-40%
Goroutines	4015	3076	-23%
CPU	1.07 cores	0.67 cores	-37%

全顧客向けself-managed OAuth

OAuthを全顧客に開放することは、より広いCloudflareアプリエコシステムに向けた重要な一歩です。現在、あらゆるCloudflare顧客が自分でOAuthアプリケーションを作成し、Cloudflare上で統合を構築できます。我々はCloudflare self-managed OAuthを全顧客向けにローンチできることを非常に嬉しく思っています。

開始方法:

• ドキュメントを参照してください（ドキュメントへのリンクは製品ページやDevelopersサイトをご利用ください）。
• ダッシュボードのOAuth appsページに直接移動して、最初のOAuthアプリを作成してください。

タグ: Developers, API, Security, OAuth, Developer Platform, Agents, Product News, Cloudflare Media Platform, Identity