世界を動かす技術を、日本語で。

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

概要

  • Cloudflare が全ユーザー向けに 自己管理型OAuth を公開
  • OAuthエンジンの大規模アップグレード で信頼性とパフォーマンス向上
  • 権限管理・同意・取り消し体験 の強化
  • 開発者によるSaaS連携や社内ツール構築 が容易に
  • 今後の Cloudflareアプリエコシステム拡大 の基盤整備

CloudflareプラットフォームにおけるOAuthの全ユーザー開放

  • Cloudflare は、全Webの約20%を支えるサービス基盤

  • 開発者は他社の多様なツールと Cloudflare API を組み合わせて自動化やCI/CD、インテグレーションを実現

  • 2024年6月、 自己管理型OAuth の提供を発表

  • これにより、各顧客が 自分専用のOAuthクライアント を作成・管理可能

  • 以前は一部限定パートナーのみ利用可能だった OAuth が、全開発者へ一般公開

    • 従来はAPIトークン利用が主流で、管理や委譲用途に課題
    • 同意・取り消し・セキュリティ のモデルを強化し、ユーザー体験向上
    • SaaS連携・社内開発者プラットフォーム・エージェント系ツール での活用が容易に

エコシステム拡大とセキュリティ強化

  • 限定的なOAuth運用から、 大規模な顧客・開発者向け に拡張

  • 権限モデル・同意画面・悪用対策 を全面的に見直し

    • アプリのアクセス要求内容・権限範囲を明示化
    • ダッシュボード上で アクセス権の取り消し が容易
    • アプリ所有者情報の可視化で OAuthフィッシング攻撃 を抑止
  • OAuthエンジンの大規模アップグレード を計画

    • ユーザー影響を最小限に抑えつつ、 データ安定性・セキュリティ を維持

OAuthエンジンアップグレード計画と実行

  • 旧バージョンの Hydra(オープンソースOAuthエンジン) を採用

  • プラットフォーム成長に伴い、 1.X→2.X への段階的アップグレードを決断

    • まず 1.X系最新リリース へ移行し、挙動やパフォーマンスを評価
    • その後、 2.X系 への本格アップグレードを実施
  • データベーススキーマ変更 による影響を最小化

    • インデックス作成時の排他ロック回避のため CREATE INDEX CONCURRENTLY を利用
    • *SELECT 問題 を解決するため、明示的なカラム指定にカスタムHydraを導入
  • ブルーグリーン方式 で2.Xアップグレードを実施

    • 書き込み停止オプションは利用せず、一部データ損失リスクを許容しつつ トークン有効期限延長 で影響抑制
    • Cloudflare Queues を用いて、アップグレード中の 権限取り消し操作 をキューに記録し、切り替え後に再適用

アップグレード実施と課題対応

  • 1.Xアップグレード はスムーズに完了、ユーザー影響なし

    • 新バージョンでのリフレッシュトークン無効化挙動が厳格化
    • Wrangler/MCPクライアント 向けに リフレッシュトークン合流処理 を追加し対処
  • 2.Xアップグレード は低トラフィック時間帯に実施、約3時間で完了

    • 移行後、一部の OAuthセッションデータ破損 による403エラー増加を検知
    • データ復旧と認可処理の改善を迅速に実施
  • その他、クライアント固有の細かな不具合も迅速に修正

  • 結果として、 システムパフォーマンス・信頼性が大幅向上

パフォーマンス改善指標

  • データベース移行時の主な統計

    • 更新行数:約1.3億件
    • 挿入行数:約1.1億件
    • 一時領域使用量:約137GB
    • トランザクションコミット数:22,200回
  • Hydraパフォーマンス改善

    • API P95レイテンシ:185ms→101ms(-45%)
    • RSSメモリ使用量:888MB→763MB(-14%)
    • Goヒープ割当:449MB→271MB(-40%)
    • Goroutine数:4015→3076(-23%)
    • CPU使用率:1.07コア→0.67コア(-37%)

すべてのユーザーに自己管理型OAuthを開放

  • 全CloudflareユーザーがOAuthアプリを作成可能
  • Cloudflareエコシステム拡大 の重要ステップ
  • SaaS連携や独自ツール開発 の基盤強化
  • 開発者向けに ドキュメントやダッシュボード から簡単に導入開始可能
  • 今後の アプリエコシステムの成長とセキュリティ向上 に大きく貢献

Hackerたちの意見

どういう意図なのかよくわからないけど、これがうまくいく世界はないよね。Cloudflareはインフラ提供者みたいなもんだし、ユーザーが自分のアカウントの権限を第三者のクライアントに委譲するってアイデアは、悪用されるリスクが高すぎる。AWSみたいな企業がやらないのは、ちゃんとした理由があるからだよ。

これって、例えばGoogleの開発者プログラムとどう違うの?あそこではGoogleユーザーのために新しいOAuthクライアントを作れるけど。

OAuthが何か理解してる?APIキーみたいなもんだけど、悪用される可能性が低いんだ。これはいいことだよ。セキュリティをいろんな面で助けてくれるし、トークンを持ち歩くよりも安全なセキュリティフローを作れる。

AWSはまさにこれをやってる。例えば、IAMが特定のリポジトリで動いているGitHubアクションにLambdaを更新する権限を与えることができる。

OAuthとエンタープライズ認証は、今までで最悪のものだと思う。クラウドを扱う中で一番混乱するし、イライラする部分かも。AIツールですら、ブラウザを開ける前提でないヘッドレスシステムで基本的なOAuthを動かすのに1年かかったし。もしRBACやIAM、ワークロードアイデンティティ、サービスアカウントみたいな大手クラウドプロバイダーのゴミを持ち込むなら、個人用にはシンプルなものだけは残してほしい。APIキーが欲しいだけなんだ。秘密にして必要なら取り消すし、あらゆるプラットフォームのあらゆるレイヤーに10000層の認証のゴタゴタを絡ませる必要はない。

君の意見に同意したい気持ちもあるけど、実際にOAuthを実装したことはないから、ドキュメントをざっと読んだだけなんだ。いつもこの複雑さには何か良い理由があると思ってた(セキュリティとか?)。

俺が理解できないのは、なぜOAuthがプライバシーの文脈であまり話題にされないのかってこと。OAuthプロバイダーは、君がログインしたサイトやその時間を全部知ってるんだから、プライバシーの悪夢だよ。

OAuthの脆弱性に関するセキュリティレポートを見たけど、今まで読んだ中で最悪だった。全体がスパゲッティみたいで、「なんとか動く」けど、似たようなものを与えると動かなくなる。OAuthには触れたくない、マジでクソな仕様だよ。

誤解しないでほしいけど、データによると、そのAPIキーを秘密に保つのは難しいし、必要になったときに取り消すのも失敗する可能性が高いよ。頻繁にローテーションすることも絶対にできないと思う。OAuth2/OIDCの良いところは、APIキーの保持者に信頼を置くんじゃなくて、アクセスが必要な実際のアイデンティティに信頼を置くところだね。

OAuthは、共通のアイデンティティ情報を共有するアプリがたくさんある場合には便利だけど、確かにクラシックなワークフローよりは優れていると思う。ただ、複雑すぎるのは同意するし、アプリ間の認証はあまり重視されてないよね。私はまだ静的な共通シークレットを使ってるけど、それに問題は感じてない。アプリが自分でパスワードを保存するのは嫌だな、たとえ今はいいツールがあって、標準のbcrypt呼び出しがそこそこ安全でも。パスワードリセットのフローを再実装しなきゃいけないし、そういう面倒なことがあるから。そういうのを中央集権化するのは、自己ホスティングのOIDCサービスをお勧めする理由だね。そのコントロールがあれば、GDPRみたいな法律にも簡単に対応できるし、ユーザーを一つのシステムで一掃すればいいから。IAMや大手プロバイダーには本当にイライラするよ。そんなのに時間を使ってられないし、効率的な解決策にはならないから。

他の試された中で最悪の委任認可システムだよ。

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にとって良いものだと思うけど、どこでも通用するわけじゃないからね。複雑さがシステムのセキュリティを難しくするから。

Hacker Newsで議論の続きを見る