すべての顧客向け Cloudflare OAuth

 (blog.cloudflare.com)
5 ポイント 投稿者 GN⁺ 4 시간 전 | 1件のコメント | WhatsAppで共有
  • Cloudflare は、顧客が self-managed OAuth アプリを自ら作成できるようにし、Cloudflare API へのアクセスを標準的な委任認可フローで提供できるようにした
  • 以前は、一部の手動でオンボーディングされたパートナーだけがサードパーティ OAuth を利用でき、自社統合を開発する開発者は委任型アプリのフローに適さない API トークン に依存する必要があった
  • 全面公開に向けて、同意画面、取り消し、アプリ所有権の表示を改善し、OAuth エンジン Hydra を 1.X から 2.X へ段階的にアップグレードした
  • アップグレードでは、スキーママイグレーション、トークン更新エラー、取り消しイベント消失のリスク、403 の増加が発生し、同時インデックス作成・取り消し再生キュー・データ復元で対応した
  • アップグレード後、API P95 は 185ms から 101ms へ 45% 減少し、CPU 使用量も 1.07 コアから 0.67 コアへ下がり、公開 OAuth 運用基盤が安定化した

Cloudflare OAuth の公開範囲を拡大

  • Cloudflare はこれまでも、プラットフォーム API を使って自動化、CI/CD、インフラ統合を構築できるようにしてきたが、今回 self-managed OAuth をすべての顧客に公開した
  • Cloudflare OAuth 自体は新機能ではなく、Wrangler や PlanetScale のようなパートナー統合で既に利用されてきた
  • ただし従来のサードパーティ OAuth は、少数の手動オンボーディングされた統合にしか提供されておらず、より広い開発者エコシステムには開かれていなかった
  • 自社統合を作る開発者は API トークン に依存せざるを得ず、この方式は管理が難しく、多くの委任型アプリケーションフローにも適していなかった
  • self-managed OAuth を使えば、開発者は顧客自身がスコープ指定されたアクセスを承認する標準的な OAuth フローを提供できる
    • 主なユースケースは SaaS 統合、社内開発者プラットフォーム、エージェントツール
    • ユーザーは、より明確な同意、簡単な取り消し、アプリケーション権限に対するより大きな制御を得られる

全面公開に向けたセキュリティ基盤の整備

  • 初期の OAuth ソリューションは少数の管理対象パートナーには十分だったが、全顧客への公開に向けては権限モデル、同意体験、悪用軽減の仕組みが十分に成熟していなかった
  • Cloudflare は今年初めに同意体験を改善し、どのアプリケーションがアクセスを要求しているのか、どの権限を得るのかをより明確に表示するようにした
  • ダッシュボードには 取り消し機能 を追加し、開発者がどのアプリケーションにデータアクセスを許可するかを容易に制御できるようにした
  • OAuth フィッシング攻撃を減らすため、アプリ所有権 もより見えやすくした
  • self-managed OAuth をすべての顧客に開放するには、ユーザーへの中断を最小化しつつ、データの安定性とセキュリティを保つ OAuth エンジンのアップグレードが必要だった

Hydra 1.X アップグレードの準備

  • Cloudflare は長年、オープンソース OAuth エンジン Hydra を Cloudflare OAuth の内部エンジンとして利用してきた
  • 開発者プラットフォームが成長し、エージェントワークフローが増える中、新機能と性能改善のための大規模アップグレードが必要になった
  • 一度に大きなアップグレードを行うのではなく、まず最新の 1.X リリースへ移行し、その後に挙動と性能の変化を評価してから 2.X アップグレードへ進む段階的な方式を選んだ
  • 1.X へのアップグレードだけでも顧客影響の可能性があった
    • Hydra データベースが重要なテーブルに 排他ロック を取る形でインデックスを作成する
    • 重要なテーブルにカラムを追加し、別のカラムを新しいテーブルへ移す
    • 利用中だった Hydra バージョンの SDK が SELECT * を実行するため、スキーマ変更時にデシリアライズの問題が起こり得た
  • ユーザー影響を防ぐため、SQL マイグレーションを CREATE INDEX CONCURRENTLY のような方式に書き換え、SELECT * の代わりに 明示的なカラム を選択するカスタム版 Hydra を作成した

Hydra 2.X アップグレード戦略

  • 2.X アップグレードはスキーマ変更の規模が大きく、インプレースアップグレード には向いていなかったため、Cloudflare は blue-green 戦略を選択した
  • 単純に新バージョンへ切り替えるだけでは不十分だった
    • アップグレードとマイグレーションには数時間を要する
    • その間もシステムが正しく動作し続ける必要があった
  • 最初の blue-green 案は、データベース書き込みを止めて新しい認可をブロックする方式だった
    • 切り替え中も新しい書き込みは失われない
    • 既に有効な認証情報を持たないユーザーは既存の OAuth アプリを使えない
    • アップグレード中にユーザーはアプリケーションアクセスを 取り消し できない
  • 最終戦略は、データベース書き込みを維持しつつ、一部の書き込み損失を許容し、そのリスクを減らす方式だった
    • 新しいトークン書き込みを減らすため、トークン有効期限を数時間に延長した
    • アップグレード前にトークンを取得したアプリは、新たに更新せずそのまま利用できる
  • 取り消しイベントの消失は Cloudflare Queues ベースのキューシステムで防いだ
    • 取り消しイベントが発生すると、その情報をキューに記録する
    • green バージョンのデータベースへ切り替えた後、キューを空にしてアップグレード期間中の取り消しを再生する
    • この処理に失敗すると、ユーザーが取り消したアプリケーションのアクセスが意図せず復元される可能性があった

1.X アップグレードとトークン更新の問題

  • 最新 1.X リリースへの最初のアップグレードは、運用面では大きな問題なく進行した
  • カスタムのデータベースマイグレーションは予想より速く実行され、ユーザー影響もなかった
  • 旧バージョンは新バージョンで生成されたトークンをイントロスペクションできず、ハードカットオーバー が必要だった
  • カットオーバー後、それまで見えていなかった refresh token エラーが増加した
    • 新バージョンのより厳格な refresh 無効化動作が原因だった
    • refresh token が再利用されると、Hydra は access token と refresh token のチェーン全体を無効化する
    • Wrangler と MCP クライアントはリクエスト量が多く、一度の refresh token 再利用でセッション全体が無効化される可能性があった
  • Cloudflare は OAuth トラフィックを正しい宛先へルーティングする Worker に refresh token coalescing の動作を追加した
    • Hydra に届く前に refresh token リクエストを短時間キャッシュする
    • リトライを検知した場合、トークンを無効化せずリクエストを短絡処理して応答する
    • Hydra 2.X には、チェーン全体を無効化せず一定時間 refresh token の再試行を許可する設定可能な refresh token grace period がある

2.X 切り替えと復旧プロセス

  • Cloudflare は、ユーザー影響の大きい数時間の停止を許容できず、blue-green アップグレードを実施した
  • 実際の切り替えには、単なるデータベースコピーと新しい Hydra デプロイ以上の作業が必要だった
    • 取り消し再生キャプチャキューの有効化
    • データベースのコピーと新しいターゲットへの復元
    • 新バージョンの制約に違反する既存データの整理
    • Hydra サービスと 2 つの主要内部システムの同時カットオーバー
    • カットオーバー後の監視と検証
  • アップグレード時間帯は、Hydra の秒間リクエスト数が最も少ない時間に選び、トークン書き込み損失を最小限に抑えた
  • 本番マイグレーションは、一部のタイムアウト調整を除けば新しいデータベース上でうまく実行され、純粋な実行時間は約 3 時間 だった
  • トラフィック切り替え直後、authorization service のデータ整理処理が OAuth policy データを過剰に削除する現象が発生した
    • そのサービスは Hydra の consent session API に依存していた
    • Hydra マイグレーションの一部が、一部の有効な OAuth セッション状態を破損させ、有効なセッションを無効と見なしていた
    • Hydra と authorization service の不整合は 403 の増加 として表れた
  • Cloudflare はデータ復元で緩和し、静的な policy データへの依存を減らすための OAuth authorization 動作改善にも着手した
  • そのほか、クライアント固有の挙動から生じた小さな修正も迅速に反映された

アップグレード後の性能改善

  • Hydra バージョンアップ完了後、OAuth トラフィックは安定して維持され、顧客向けシステムの性能と信頼性が向上した
  • 新しい基盤は、staging で既に検証済みの新 OAuth API と同じ基盤であり、6 月 3 日の self-managed OAuth リリース を可能にした
  • データベースマイグレーション中に観測された主な数値:
    • 更新された行: 132.5M
    • 挿入された行: 114.7M
    • 一時バイト: 136.97GB
    • トランザクションコミット: 22.2k
  • Hydra の平均性能指標はアップグレード後に全体的に改善した
    • API P95: 185ms → 101ms、45% 減少
    • RSS メモリ: 888MB → 763MB、14% 減少
    • Go heap alloc: 449MB → 271MB、40% 減少
    • Goroutines: 4015 → 3076、23% 減少
    • CPU: 1.07 コア → 0.67 コア、37% 減少

始め方

  • 現在、すべての Cloudflare 顧客は独自の OAuth アプリケーションを作成し、Cloudflare 上で統合を構築できる
  • 始めるには、ドキュメント を読むか、ダッシュボード の OAuth apps ページで最初の OAuth アプリを作成できる

関連記事

1件のコメント

 
GN⁺ 4 시간 전
Hacker Newsのコメント

  • Ory Hydraの作者です。このブログ記事と技術的な説明を見て、本当にうれしく思いました。このソフトウェアが世界のインターネット企業を守ることになるとは想像もしていませんでした。
    2.xバージョンがその規模でうまく動いているのは良いことですし、CPU使用率も信じられないほど小さく見えます。
    問題が発生した場合は、より高速な商用版もあります。独自OAuth、IAM、ReBAC権限、APIキー、エージェントセキュリティに関心があれば、オープンソースと商用製品を https://github.com/ory と https://www.ory.com/ で見られます

  • 以前、dotnet向けの identity server フレームワークをセルフホストで運用し、毎月数十億件のリクエストを処理していましたが、その規模の OAuthとOpenID Connect は実質的に解決済みの問題に近く、保守負担も低いものでした。
    組織の中核サービスであり、コンプライアンス要件も厳しかったですが、担当チームはおそらく3人程度で、今でも問題なく動いています。
    このプロトコルについてなぜそんなに混乱が多いのか理解できませんでしたし、一緒に働いたほぼすべてのジュニアエンジニアが理解に苦労していました。Scott Brady のブログ https://www.scottbrady.io/ はこのテーマで非常に役立ちます。
    認証/認可が絡むと、エンジニアには原始的な「恐怖」が生まれるようです。問題解決には慣れていても、認証/認可はその問題解決の前提条件のように入り込んできて、認知コストを生むのだと思います。

    • dotnet向け identity server が商用製品に変わって、利用コストがとんでもなく高くなったあの製品のことですか？ Lite でも年 ほぼ6000ドル から始まります: https://duendesoftware.com/pricing

  • いかにもCloudflareらしいです。みんなのためによく動き、それほど高くもありませんが、そのあらゆる利点の結果として あらゆるものの中心 に居座ることになります。

    • Cloudflare は基本範囲を外れると、最も高価なプロバイダーの1つです。動画ストリーミング の価格を見れば分かります。
    • それならフェアな取引ではないでしょうか。

  • Grantです。Aeneas と一緒に 2.0マイグレーションコード の大部分を書きました。Cloudflare チームの記事に感謝します。
    「調査の結果、Hydra のマイグレーションの1つに問題があり、一部の有効なOAuthセッションの状態が破損し、その結果マイグレーションがそのセッションを無効とマークした」という部分が、オープンソースのマイグレーションファイルの1つだったのか気になります。
    もうこのプロジェクトには関わっていませんが、upstream で修正されたのか知りたいです。

  • 全体の文脈には、少なくともCloudflareエコシステム内での 認可と認証フロー の計画も含まれているべきで、複雑な気持ちです。GitHub の例もありません。
    それでも Cloudflare が正しい方向に出発したのは確かですが、基盤となる Ory の製品群全体と比べると、まだ道のりは長いです。Ory Kratos はアイデンティティ、ログイン、登録、リカバリー、多要素認証などを処理します: https://github.com/ory
    全体の範囲には、ユーザーストア、SAML、マルチテナント組織モデルの計画も含めるべきだと思います。良い例として、Zitadel https://github.com/zitadel は組織マルチテナンシー向けの管理UI、OIDC/PKCEサポートなどを提供し、RBACもある程度追加できます。
    Supabase もマネージドおよびオープンソースの認証を提供しています: https://github.com/supabase/auth
    「MCPは死んだ、Skillsよ永遠なれ」はさておき、これらすべてで MCP を組み込み、キーをローテーションする計画が近いうちに大きく問題化しそうで心配です。
    OAuth 2.0 動的クライアント登録（RFC 7591）: https://datatracker.ietf.org/doc/html/rfc7591
    https://modelcontextprotocol.io/specification/2025-03-26/bas...
    特にマルチテナントSaaSと組み込み AIアシスタント の文脈で意見を聞いてみたいです。

    • 最近、IAMベンダーと MCP サービスを保護する作業をしましたが、その文脈では OAuth動的クライアント登録 はかなり怖く感じられます。
      MCP をエージェントに接続する際によく使われるリダイレクトフローについて、仕様はそれをどう安全にするかをほとんど語っていません。
      誰でも任意のコールバックでクライアントを登録できるようにはしたくありません。それはフィッシングにさらされる道です。
      悪意あるコールバックURLでクライアントを登録したうえで、ユーザーをだましてそのフローを開始するリンクをクリックさせれば、正当なIDプロバイダーがユーザーを認証した後、アクセストークンを攻撃者に渡してしまうことになります。
      仕様は、クライアントが登録前にまず取得する初期アクセストークンについて触れてはいますが、詳細が不足しており、すべてのエンドユーザーがクライアントになる状況では、おそらくうまく機能しません。
      理想的には、リダイレクトパターンの許可リストを指定して、ChatGPT のような対象に制限したいところです。しかしこれは非標準の挙動なので、IAMベンダーは急いでいません。

  • ここで何を意図しているのか分かりません。うまく終わる世界が見えません。Cloudflare はほとんどインフラプロバイダーなのに、あるユーザーが自分のアカウント権限をサードパーティークライアントに委任できるインフラ向けモデルには、悪用の可能性 が大きいです。
    AWS のような会社がやっていないのなら、それなりの理由があるのだと思います。

    • AWS はまさにこれをやっています。
      たとえば IAM では、特定のリポジトリで実行される GitHub Actions に Lambda の更新権限を与えられます。
    • OAuth が何か理解していますか？ APIキーに似ていますが、悪用される可能性はより低いです。良いことであり、さまざまな形でセキュリティを助け、トークンを持ち歩くよりもセキュリティフローを安全にします。
    • Google ユーザー向けに新しいOAuthクライアントを作成できる Google デベロッパープログラム と、どれほど違うのか分かりません。

  • OAuthとエンタープライズ認証は、作られたものの中でも最悪かもしれない。クラウドを扱うときに、最も混乱しやすくいら立たしい部分になり得る
    AIツールでさえ、ブラウザを開けることを前提にせずヘッドレスシステムで基本的なOAuthを処理するだけで1年かかった
    RBAC/IAM/ワークロードID/サービスアカウントのような大手クラウドプロバイダーのありとあらゆる認証のウサギ穴に潜るのだとしても、個人利用向けのシンプルな方法はどうか残しておいてほしい
    APIキー1つで十分。秘密として保管し、必要なら失効させればよく、あらゆるプラットフォームのあらゆる層で認証のがらくたが1万層も絡み合う必要はない

    • OAuthがプライバシーの文脈でほとんど語られない理由が分からない。OAuthプロバイダーは、ユーザーがどのサイトにいつログインしたかをすべて知ることになる
      プライバシー上の悪夢だ
    • OAuth2は複雑で、しばしば適切な道具ではない。Ory Hydraを作り、OAuth2が良い選択である場合とそうでない場合を扱った記事も書いた: https://www.ory.com/blog/oauth2-openid-connect-do-you-need-u...
      APIキー向けにはOry Talos(https://github.com/ory/talos)をリリースしたばかりだ。OAuth2がユースケースに対して過剰な場合の良い代替になる
      OAuth2の利用を正当化するユースケースやセキュリティ上の懸念もある。DPoPのような仕様で、こうしたフローをより安全にできる
      ここで示されているユースケースはOAuth2に適しているように見えるが、どこにでも合うわけではない。複雑さはシステムの安全性をより難しくする
    • 一般的なログインフローまで完全に壊してしまった感じだ。以前はパスワードマネージャーがユーザー名とパスワード欄を自動入力してくれたのに、OAuthのせいでユーザー名欄しか出なかったり、「パスワードでログイン」のようなボタンを先に押さなければならないばかげた手順がよく生じる
    • データ的には、そのAPIキーを秘密のまま維持することに失敗する可能性が高く、必要なときに失効させることにも失敗する可能性が高い。もちろん必要な頻度でローテーションもしないだろう
      OAuth2/OIDCの利点は、信頼をAPIキーの所持者に置かず、アクセスが必要な実際の身元に置けることにある
    • それならアプリケーションに直接実装すればいい。ランダムなキーを生成してハッシュとソルトを保存すれば終わりだ
      認証が難しいというのは、多数のユーザー向け認証の話だ。自分自身のための認証はとても単純で、まともなフレームワークを使えばさらに簡単になる
      実装に不安があるなら、最新モデルのどれかに投げればいい。そういう単純な認証システムの問題を見つけるのはかなり得意だ

  • 「Ory Enterprise License: CVEセキュリティSLA、SAML、B2B組織、マルチテナンシー、より良い拡張性のようなエンタープライズ級機能をアンロック」[0]
    あるいは、完全なセルフホスティング製品を提供しているKeycloakをそのまま使い続ければいい [1]
    [0]https://github.com/ory
    [1]https://www.keycloak.org/

    • たとえば社内従業員向けにフルのJavaサーバースタックを運用したいならKeycloakは素晴らしいが、Oryは大規模運用、たとえばOpenAI https://www.ory.com/case-studies/openai のような事例と組み合わせられるやり方でははるかに優れていると思う
      商用版がある理由は、世界級のオープンソースをどう財政的に持続させるかという問題があるからだ。地球上で最大級のソフトウェア企業を支えるオープンソースに機能するビジネスモデルがあるのは、悪いことではなく良いことだ
      ちなみにIBMもKeycloakで収益化する方法を見つけている
    • 本番環境でKeycloakを扱ったことがあるが、それほど素晴らしくはない。内部でInfinispanとJGroupsを使っていなければ、もっと良かったかもしれない。どちらも理由もなくばかげて複雑だ
    • Keycloakだ

  • これは基本的にCloudflareアカウントへのアクセス用OAuthの話であって、カスタムアプリ向けのCloudflareホスティングの汎用「ログイン」機能の類ではない

    • 私も最初は後者を思い浮かべて、何を提供するのか気になった

  • OAuthが何かは理解していると思っていたが、この記事は混乱する。クライアントごとのアクセスキーを提供する標準化プロトコルだと思っていた
    ここでいうセルフマネージドOAuthとは何なのか。何へのアクセス権が付与され、クライアントは誰で、パートナーは誰なのかの説明が必要だ

    • 「今月初め、顧客がCloudflare APIへの委任アクセス用OAuthクライアントを自分で簡単に作成・管理できるようにするセルフマネージドOAuthを発表した」という意味だ
      自身のリソースへのアクセスを承認・拒否するOAuthシステムを自分でホストできるようにするものだ。CloudflareがX条件でYを許可してくれるのを待つ代わりに、望むロジックを作れる
      本質的には「Cloudflareにログイン」→ CloudflareがセルフマネージドOAuthの使用を確認 → ユーザーのOAuthへリダイレクト → Cloudflareが応答を信頼 → ユーザーが承認すればアカウントアクセスを許可、というフローだ
    • 基本的には自前の認可サーバーをホストできるという意味だ