OAuthで、すべての人にCloudflareアプリエコシステムを開放

このコンテンツは自動機械翻訳サービスによる翻訳版であり、皆さまの便宜のために提供しています。原本の英語版と異なる誤り、省略、解釈の微妙な違いが含まれる場合があります。ご不明な点がある場合は、英語版原本をご確認ください。

CloudflareはWebの20%の稼働を支えるサービスを提供していますが、これは当社だけでは実現しません。当社のプラットフォームの開発者は、他社が提供するさまざまなツールやサービスも利用しています。Cloudflareは、開発者がインフラストラクチャのさまざまな部分をつなぎ合わせる自動化、CI/CD、統合を作成できるような充実したAPIを提供しています。今月初め、Cloudflareは自己管理型OAuthを発表しました。これにより、お客様はCloudflare APIへの委任アクセスのために独自のOAuthクライアントを容易に作成・管理することが可能になります。

CloudflareはOAuthにとって新しいわけではありません。Wranglerを使ったことがある方や、PlanetScaleなどのパートナーの統合機能を使ったことがある方は、すでに利用していることでしょう。しかし、これまでサードパーティのOAuthは、手動でオンボードされる統合を通じてのみ利用でき、より広範な開発者が利用できるものではありませんでした。つまり、独自の統合を構築する開発者はAPIトークンに頼らざるをえないのが現状ですが、APIトークンは管理が難しく、多くの委任されたアプリケーションフローには適していません。

昨年、当社は、Cloudflare OAuthの背後にある同意、取り消し、セキュリティモデルを改善する一方で、早期パートナーの数を増やしてきました。しかし、当社の開発者プラットフォームが成長し、エージェンティックツールによるアクセス移管の需要が高まるにつれ、当社のプラットフォームの成功に、すべてのお客様にOAuthを開放することが極めて重要だと関わるようになりました。

自己管理型OAuthにより、開発者は、顧客が範囲付きアクセスを直接許可する標準OAuthフローを提供できるようになり、SaaS統合、内部開発者プラットフォーム、エージェンティックツールの構築を容易にし、ユーザーに明確な同意、より簡単な取り消し、より詳細な制御を提供できるようになります。使用できるのです。

以前のOAuthソリューションは、慎重に管理された少数のパートナーに対しては十分でしたが、許可モデル、同意の経験、潜在的な不正利用ベクトルを軽減する方法は、十分に成熟していないと認識しました。

今年初め、私たちは同意エクスペリエンスを更新し、どのアプリケーションがアクセスを要求しているか、そしてどのような許可を受けるかをより明確にしました。また、ダッシュボードに取り消し機能を追加して、開発者がデータにアクセスできるアプリケーションを簡単に制御できるようにし、OAuthフィッシング攻撃を防ぐために、アプリの所有権をより可視化しました。

自己管理型OAuthをすべてのお客様に公開するには、基盤となるOAuthエンジンにも大きなアップグレードが必要でした。このプロセスには、ユーザーの中断を最小限に抑えながら、データの安定性とセキュリティを確保するための多くの計画が必要でした。

数年前、私たちはCloudflare OAuthを内部で稼働させるために、オープンソースのOAuthエンジンであるHydraをデプロイしました。このデプロイメントは、利用が限られていたときはうまく機能していましたが、開発者プラットフォームが成長し、エージェントワークフローが一般的になるにつれ、新しい機能を解放し、パフォーマンスを向上させるためのメジャーなアップグレードが必要であると感じました。

今回のアップグレードを計画する際、1回の大規模なアップグレードではなく、2回の小規模なアップグレードを実施することにしました。まず、最新の1.Xリリースに移行し、動作やパフォーマンスの変更を評価した後、2.Xへのアップグレードを進めます。

アップグレード計画中に、Hydraデータベースは以下のような広範なスキーマ移行を必要とするため、1.Xにアップグレードしても、依然としてお客様に影響を与えることが明らかになりました。

1. 重要なテーブルを排他的ロックとみなすような方法でインデックスを作成し、アクティブユーザーが重要なOAuth操作をできないようにする

2. 重要なテーブルに列を追加し、他の列を新しいテーブルに移動しました

また、私たちが使用していたHydraのバージョンには、SDKがSELECT *操作を実行するという異常があり、スキーマの変更に関してデシリアル化の問題が発生していました。

ユーザーへの影響を防ぐために、SQLマイグレーションを書き直して、CREATE INDEX CONCURRENTLYなどの機能を使用し、SELECT *ではなく明示的な列を選択したHydraのカスタムバージョンを構築しました。

最新の1.Xアップグレードが計画されていたため、さらに大きな2.Xアップグレードの計画を立てる必要がありました。私たちは3つの潜在的な選択肢を特定し、それぞれの利点と欠点を比較しました。インプレースアップグレードは、主要なバージョンバンプがもたらすスキーマの変更の量があまりにも多いため、うまくいきませんでした。ブルーグリーン戦略が有効だと判断しましたが、新しいバージョンを使い始めるには、スイッチを切り替えるだけでは不十分でした。アップグレードと移行のプロセスには数時間かかり、その間もシステムが正常に機能し続ける必要がありました。

最初の青緑の選択肢は、データベースへの書き込みを無効にし、新しい認可が発生するのを防ぎます。つまり、移行中に紛失することはありませんが、有効な認証情報をすでに持っていない限り、既存のOAuthアプリを使用できないことも意味します。また、別の大きな問題が発生しました。ユーザーが何らかの理由でアプリケーションからのアクセス権を取り消す必要がある場合、アップグレードの実行中は実行できません。

これらの問題に対処するために、データベースへの書き込みを有効にしておく方法を考案しましたが、グリーンバージョンに切り替えると一部が失われます。まず解決すべきは、新しいトークンの書き込み回数を最小限に抑えることでした。トークンの有効期限を数時間に延ばすという、運用上の圧力があったのです。これにより、アップグレード前に新しいトークンを受け取ったアプリは、更新する必要なくそれらを引き続き使用できます。

書き込み削減を解決した後、アップグレード期間中にユーザーが実行した取り消しを失わない方法を見つける必要がありました。これを行うために、キューシステム（Cloudflare Queuesを使用）を作成しました。取り消しイベント後に、その取り消しに関する情報を含むレコードがキューに書き込まれます。これにより、データベースを緑色のバージョンに切り替えてキューを解消し、失われたタイムウィンドウに発生したすべての取り消しイベントをリプレイすることができます。この権利を守るためには、ユーザーが無効にしたアプリケーションのアクセス権が誤って復元されてしまうため、非常に重要でした。

運用上の観点からは、最後の1.Xリリースへの最初のアップグレードは問題なく完了しました。カスタムデータベースの移行は予想よりも速く実行され、ユーザーへの影響はありませんでした。古いバージョンは、新バージョンによって作成されたトークンをイン検査できないため、新しいバージョンへのハードな移行を実施しなければなりませんでした。

カットオーバー後に、以前は見られなかったリフレッシュトークンエラーが増加しました。これは最終的に、新バージョンでのリフレッシュの無効化の動作が厳格化したためです。リフレッシュトークンが再利用されると、Hydraはアクセストークンを無効化し、トークンチェーン全体を無効化します。これは、WranglerとMCPクライアントにとって問題です。これらのクライアントはどちらもリクエスト量が多く、単一の再利用されるリフレッシュトークンがセッション全体を無効化します。

Cloudflareは、OAuthトラフィックを正しい宛先にルーティングするWorkerにリフレッシュトークンの結束動作を追加することで、この問題を軽減しました。これにより、Hydraに到達する前にリフレッシュトークンリクエストを一時的にキャッシュできるため、リトライを検出した場合も、トークンを無効化することなくリクエストを短時間で応答することができました。幸いなことに、Hydraの2.Xバージョンには設定可能な「リフレッシュトークンの猶予期間」があり、チェーン全体を無効化することなく、一定期間のリフレッシュトークンを再試行できるようにすることで、この問題を解決します。

何時間にもわたり、ユーザーに対して高い影響を与えることは許容されないため、ブルーグリーン色のアップグレード戦略を設定しました。これは大まかに言えば、簡単に聞こえます。移行は本番データベースのコピーで実行され、完了後に新しいHydraバージョンに合わせて移行されます。実際には、はるかに多くの可動部分がありました。

• 取り消しリプレイキャプチャキューの有効化

• データベースをコピーして新しいターゲットに復元する

• 標的型データクリーンアップ：既存のデータが、新バージョンで導入されたいくつかの新しい制約に違反したため、移行の成功を妨げる可能性がある

• Hydraサービスと2つの重要な内部システムの両方を同時にカットオーバーし、エラーを防止する

• カットオーバー後の監視と検証

当社は、Hydra社の1秒あたりのリクエスト量が最も少ない時に、アップグレード期間を選択し、トークンの書き込み損失を最小限に抑えることができました。本番移行は、若干のタイムアウト調整を除いて、新しいデータベースに対してうまく機能しました。本番移行の正味ランタイムは約3時間でした。移行完了後、Hydraサービスの新バージョンと、システムを有効にして新しいSDKバージョンを使用できるようにするための2つの追加のシステム設定を慎重に展開しました。

トラフィックを遮断した直後に、認証サービス（Hydra同意セッションAPIに依存する）のデータクリーンアップジョブが、OAuthポリシーデータのパージを過剰に要求していることがわかりました。調査の結果、Hydraの移行の1つに問題があり、特定の有効なOAuthセッションの状態を損なう問題があり、移行によって無効と表示されるようになったことを発見しました。有効なセッションが破損することで、Hydraと当社の認証サービスとの間で不一致が生じ、403の増加として現れました。この問題を軽減するために、データ復元を行い、静的ポリシーデータへの依存を解消するために、OAuth承認動作の改善に取り組み始めました。

データクリーンアップの問題以外にも、特定のクライアントの動作に起因する小さな修正がいくつかありました。これはすぐに見つけられるものです。

Hydraのバージョンアップグレードが完了し、OAuthトラフィックは安定した状態を維持し、お客様にとってシステムパフォーマンスと信頼性が向上しました。また、新しいOAuth APIがすでにステージングで検証されていたのと同じ基盤に本番環境をもたらし、6月3日の自己管理型OAuthリリースへの道が開かれました。

このような大規模なアップグレードが完了した後は、その影響に関するいくつかの幅広い指標を見ると、必ずやりがいがあり、状況を把握することができるのです。データベース移行中に追加のメトリクスを収集し、アップグレード完了後に大幅なパフォーマンス改善が確認されました。

すべてのお客様にOAuthを開放することは、Cloudflareアプリのエコシステムの広範化に向けた重要なステップです。現在、Cloudflareのすべてのお客様は独自のOAuthアプリケーションを作成し、Cloudflare上で統合を構築することができます。Cloudflare自己管理型OAuthをすべてのお客様に提供開始できることを大変嬉しく思います。

開始するには、ドキュメントをご覧いただくか、ダッシュボードのOAuthアプリページに直接移動して、最初のOAuthアプリを作成してください。