Cloudflareが全ユーザー向けにセルフマネージドOAuthを開始

OAuth for allでCloudflareアプリエコシステムを解放 CloudflareはWebの20%を稼働させるサービスを提供していますが、それは単独で行っているわけではありません。当社のプラットフォーム上の開発者は、他の企業の無数のツールやサービスも利用しています。Cloudflareは、開発者が自動化、CI/CD、およびインフラストラクチャのさまざまな部分を結びつける統合を作成できる豊富なAPIをプラットフォームに提供しています。今月初め、当社はセルフマネージドOAuthを発表し、顧客がCloudflare APIへの委任されたアクセスに対して独自のOAuthクライアントをより簡単に作成および管理できるようにしました。 CloudflareにとってOAuthは新しいものではありません。Wranglerを使用したことがある方や、PlanetScaleなどのパートナーからの統合機能を使用したことがある方なら、すでにOAuthを利用しています。しかし、これまでサードパーティOAuthは、手動でオンボーディングされた少数の統合を通じてのみ利用可能であり、より広範な開発者には利用できませんでした。これは、独自の統合を構築する開発者がAPIトークンに依存する必要があることを意味し、APIトークンは管理が難しく、多くの委任されたアプリケーションフローには不適切でした。この1年間で、Cloudflare OAuthの同意、失効、およびセキュリティモデルを改善しながら、初期のパートナーを増やしていきました。しかし、当社の開発者プラットフォームが成長し、エージェントツールが委任されたアクセスへの需要を促進するにつれて、すべての顧客にOAuthを開放することがプラットフォームの成功にとって不可欠であることが明らかになりました。セルフマネージドOAuthにより、開発者は顧客がスコープ付きアクセスを直接付与する標準的なOAuthフローを提供できるようになり、SaaS連携、社内開発者プラットフォーム、およびエージェントツールを構築しやすくなると同時に、ユーザーはより明確な同意、簡単な失効、およびアプリケーションが何ができるかについてより多くの制御を得ることができます。 エコシステムを安全に拡張する 当社の以前のOAuthソリューションは、少数の慎重に管理されたパートナーには十分でしたが、当社の許可モデル、同意体験、および潜在的な悪用ベクトルを軽減する方法が十分に成熟していないことに気づきました。今年初め、当社は同意体験を更新し、どのアプリケーションがアクセスを要求しているのか、およびどのような許可を受け取るのかをより明確にしました。また、開発者がデータにアクセスできるアプリケーションを簡単に制御できるように、ダッシュボードに失効機能を追加し、OAuthフィッシング攻撃を防ぐためにアプリの所有権をより可視化しました。 セルフマネージドOAuthをすべての顧客に開放するには、基盤となるOAuthエンジンの大幅なアップグレードも必要でした。このプロセスには、ユーザーへの中断を最小限に抑えつつ、データの安定性とセキュリティを確保するための多大な計画が必要でした。 OAuthエンジンへのアップグレード計画 数年前、当社はCloudflare OAuthのバックエンドを強化するために、オープンソースのOAuthエンジンであるHydraを導入しました。その導入は、使用が制限されていたときにはうまく機能しましたが、開発者プラットフォームが成長し、エージェントワークフローが一般的になるにつれて、新しい機能を解放し、パフォーマンスを向上させるために大規模なアップグレードが必要であることが明らかになりました。アップグレードを計画するにあたり、1つの大きなアップグレードを行うのではなく、2つの小さな連続したアップグレードを行うことにしました。まず、最新の1.Xリリースに移行し、動作やパフォーマンスの変更を評価してから、2.Xアップグレードに進むことになりました。 アップグレード計画中に、1.Xアップグレードでさえ顧客に影響を与えることが明らかになりました。なぜなら、Hydraデータベースには、以下のような大規模なスキーマ移行が必要だったからです。 重要なテーブルに排他的ロックをかける方法でインデックスを作成し、アクティブなユーザーが重要なOAuth操作を実行できないようにする 重要なテーブルに列を追加し、他の列を新しいテーブルに移動する また、使用していたHydraのバージョンには、SDKがSELECT *操作を実行し、スキーマ変更によるデシリアライゼーションの問題を引き起こすという特異な点がありました。 ユーザーへの影響を防ぐため、SQL移行をCREATE INDEX CONCURRENTLYなどの機能を使用するように書き直し、SELECT *ではなく明示的な列を選択するカスタムバージョンのHydraを構築しました。 最新の1.Xアップグレードが計画されたので、今度はさらに大規模な2.Xアップグレードの計画を作成する必要がありました。3つの潜在的なオプションを特定し、それぞれについてメリットとデメリットを比較検討しました。メジャーバージョンアップによるスキーマ変更の膨大な量のため、インプレースアップグレードは機能しませんでした。ブルー/グリーン戦略が機能すると判断しましたが、新バージョンの使用を開始するために単にスイッチを切り替えるだけでは不十分でした。アップグレードと移行のプロセスには数時間かかり、その時間帯にシステムが正しく機能し続ける必要がありました。 最初のブルー/グリーンオプションでは、データベースへの書き込みを無効にし、新しい認証が行われるのを防ぐことになります。これは、移行中に認証が失われないことを意味しますが、有効なクレデンシャルを持っていない限り、誰も既存のOAuthアプリを使用できないことも意味しました。また、別の大きな問題も発生しました。ユーザーが何らかの理由でアプリケーションへのアクセスを取り消す必要がある場合、アップグレードの実行中はそれが不可能になることでした。 これらの問題を解決するために、データベースへの書き込みを有効にしておく方法を考案しましたが、グリーンバージョンへの切り替えで一部の書き込みが失われるという代償がありました。最初に解決すべき問題は、新しいトークンに対する書き込みの数を最小限に抑えることでした。当社が利用した運用上のレバーは、トークンの有効期限を数時間に延長することでした。これにより、アップグレード前に新しいトークンを受け取ったアプリは、更新する必要なくそれらを使い続けることができるようになりました。 書き込みの削減が解決されたので、アップグレード期間中にユーザーが行った失効を失わない方法を考案する必要がありました。これを行うために、当社はキューシステム（Cloudflare Queuesを使用！）を作成しました。失効イベント後、その失効に関する情報がキューに記録されます。これにより、データベースがグリーンバージョンに切り替わった後、キューを空にし、失われたはずの時間帯に発生したすべての失効イベントをリプレイできるようになります。これは正しく行うことが非常に重要でした。そうでなければ、ユーザーが失効させたアプリケーションのアクセスが誤って復元されてしまうことになります。 アップグレードの実行 1.Xへのアップグレード 運用上の観点から見ると、最初の最新1.Xリリースへのアップグレードは、何の問題もなく完了しました。当社のカスタムデータベース移行は予想よりも速く実行され、ユーザーへの影響はありませんでした。古いバージョンでは、新しいバージョンによって作成されたトークンをイントロスペクトできなかったため、新しいバージョンへのハードカットオーバーを行う必要がありました。 カットオーバー後、これまで見たことのないリフレッシュトークンエラーの増加が見られました。これは、新しいバージョンでのより厳密なリフレッシュ失効動作が原因であることが判明しました。リフレッシュトークンが再利用された場合、Hydraはアクセスおよびリフレッシュトークンチェーン全体を無効にしていました。これはWranglerおよびMCPクライアントにとって問題となります。これらのクライアントは両方ともリクエスト量が多いため、単一のリフレッシュトークンの再利用によってセッション全体が無効になってしまうことになります。 これを軽減するため、OAuthトラフィックを正しい宛先にルーティングする当社のWorkerにリフレッシュトークン統合動作を追加しました。これにより、リフレッシュトークンリクエストがHydraに到達する前に一時的にキャッシュできるようになり、再試行を検出した場合にリクエストをショートサーキットし、トークンを無効にすることなく応答できるようになりました。幸いにも、Hydraの2.Xバージョンには設定可能な「リフレッシュトークングレース期間」があり、これによりリフレッシュトークンを一定期間再試行してもチェーン全体を無効にしないことでこの問題が解決されます。 2.Xへのアップグレード 数時間のユーザーへの大規模な影響は許容できないため、ブルー/グリーンアップグレード戦略を設定しました。大まかには、これは単純に聞こえます。移行は本番データベースのコピーで実行され、完了後に新しいHydraバージョンとともに切り替わります。実際には、はるかに多くの可動部品がありました。失効リプレイキャプチャキューを有効にする データベースを新しいターゲットにコピーして復元する ターゲットを絞ったデータクリーンアップ — 既存データが一部の規則に違反していた