DocsDigest
一覧へLanguage: EN
OpenAICloudflare2026/04/14 13:00

Managed OAuth for Access: make internal apps agent-ready in one click

要点だけを先に読めるように短く再構成したセクションです。

元記事
OpenAIClaude

Quick Digest

要約

要点だけを先に読めるように短く再構成したセクションです。

openaijamodel: gpt-5-mini-2025-08-07

Managed OAuth：内部アプリをワンクリックでエージェント対応

cloudflareoauthrfc9728pkcejwtaccessagents

Key Points

  • ワンクリックで有効化
  • エージェントがOAuthで認証可能
  • コード変更不要でレガシー対応

Summary

Cloudflare AccessのManaged OAuthがオープンベータになり、内部アプリをワンクリックでエージェント対応にできます。Accessが認可サーバーとして動作し、www-authenticateヘッダ経由でagentsが/.well-known/oauth-authorization-serverを発見してRFC 9728に従うOAuthフロー（動的クライアント登録 RFC 7591、PKCE RFC 7636）を実行し、JWTを取得してユーザー代行でAPIやページへアクセスします。レガシーアプリのコード変更は不要で、サービスアカウントの静的資格情報ではなくユーザー紐付けトークンで責任追跡が可能です。

Key Points

  • 有効化: Cloudflareダッシュボードで対象のAccessアプリに「Managed OAuth」をワンクリックで有効化。コード変更不要。
  • Discovery: 未認可レスポンスのwww-authenticateを参照し、https://<your-app-domain>/.well-known/oauth-authorization-server から認可情報を取得。
  • 標準フロー: 動的クライアント登録(RFC 7591) → PKCE(RFC 7636)でユーザー同意を経てJWTを取得し、Authorizationヘッダでリクエストを送信。
  • エージェント実装の推奨: web-fetchツールは401/403のwww-authenticateを処理し、ユーザーに同意を促してOAuthフローを実行できるようにする（RFC 9728準拠）。
  • セキュリティ／監査: サービスアカウント／静的トークンではなくユーザーに紐づくトークンを使い、適切なアクセス制御と監査ログを確保。
  • 運用: Open beta。組織単位でのIdP共有（複数Cloudflareアカウント横断）対応が近日提供予定。

Quick adoption steps for engineers

  • ダッシュボードでManaged OAuthを有効化。
  • エージェント／web-fetch実装がwww-authenticateと/.well-known/oauth-authorization-serverを解釈するよう実装。
  • 動的クライアント登録とPKCEを実装してユーザー承認フローを実行、受け取ったJWTをAuthorizationヘッダに付与してAPIやページへアクセス。
  • 既存のサービスアカウント運用は段階的に見直し、ユーザー紐付けトークンへ移行して監査と最小権限を維持。

Notes

  • トークンはJWTとして返され、Cloudflare Workersや外部ホストされたアプリでもそのまま利用可能。
  • RFC 9728対応により、MCP以外の一般的なWebページやREST APIもエージェントから安全にアクセス可能になる。

Full Translation

翻訳

原文の流れを保ったまま読める翻訳セクションです。

openaijamodel: gpt-5-mini-2025-08-07

Access向けManaged OAuth：内部アプリをワンクリックでエージェント対応に

概要

Cloudflare には数千の内部アプリがあります。自社で開発したものもあれば、他社製ソフトウェアのセルフホスティング版も含まれます。業務に不可欠でほぼ全員が使うアプリから、サイドプロジェクトやプロトタイプまで多岐にわたります。これらすべてのアプリは Cloudflare Access によって保護されています。

しかし、エージェント（特にコード以外の用途で使うもの）を導入・構築し始めたときに問題に直面しました。人は Access の背後にあるアプリにログインしてアクセスできますが、エージェントはできませんでした。

Access は内部アプリの前段に位置し、ポリシーを定義すると未認証のユーザーをログインページにリダイレクトして認証方法を選ばせます。人間にとってはこのフローは問題ありませんが、エージェントが受け取るのはログインページへのリダイレクトだけで、エージェント自身では処理できませんでした。

エージェントに内部アプリのデータアクセスを与えることは非常に重要なため、我々はすぐに自社用途のための暫定策を実装しました。OpenCode の web fetch ツールを修正し、特定のドメインに対して cloudflared CLI をトリガーして JWT（JSON Web Token）を取得する認可フローを開かせ、取得したトークンをリクエストに付与することで、内部エコシステムへの安全で即時のアクセスを実現しました。

この一時的なソリューションは自社の課題解決には有効でしたが、本日それを廃止し、より多くのユーザーのために根本的な解決を提供します。現在オープンベータとして、すべての Access アプリケーションが Managed OAuth をサポートします。Access アプリでワンクリックで有効化すると、OAuth 2.0 を扱えるエージェントが認証方法を容易に発見し（RFC 9728）、ユーザーを認可フローに送り、認可トークン（我々の暫定策で使っていたのと同じ JWT）を受け取れるようになります。これにより、人間とエージェントの両方にとってフローがスムーズになります。

Cloudflare Access には寛大な無料ティアがあります。さらに、新たに導入した Organizations ベータを基盤に、まもなく Cloudflare アカウント間で IdP をまたいで橋渡しする機能も提供予定です。

Managed OAuth の仕組み

内部アプリが Cloudflare Access で保護されている場合、Managed OAuth はワンクリックで有効化できます。Managed OAuth を有効化すると、Cloudflare Access が認可サーバーとして動作します。未認可のエージェントに対して www-authenticate ヘッダを返し、認可トークンを取得する方法がどこに記載されているかを通知します。エージェントはその情報を次の場所で見つけます：

https://&lt;your-app-domain&gt;/.well-known/oauth-authorization-server

この案内を得たエージェントは OAuth 標準に従って処理できます:

  • エージェントは動的にクライアント登録を行う（Dynamic Client Registration — RFC 7591）
  • エージェントはユーザーを PKCE（Proof Key for Code Exchange — RFC 7636）認可フローに送る
  • ユーザーがアクセスを承認すると、エージェントはそのユーザーを代表して認証済みリクエストを行うためのトークン（JWT）を受け取る

この認可フローは Model Context Protocol（MCP）が使うフローと同じ考え方に基づいています。我々は当初、MCP サーバー用のポータル製品にこのサポートを組み込み、ポータルが OAuth サーバーとして動作できるようにしました。今回、この仕組みをすべての Access アプリに拡張し、MCP サーバーだけでなくウェブページ、ウェブアプリ、REST API でもエージェントがアクセスできるようにします。

内部アプリを一斉にエージェント対応にする

内部ソフトウェアの長い尻尾をエージェント対応にアップグレードするのは大きな作業です。理想的には、エージェント対応するには各アプリが発見可能な API、CLI、よく設計された MCP サーバー、そして新興のエージェント標準を採用している必要があります。だが、AI の採用はすべてを後付けで整備されるのを待てるものではありません。多くの組織には何年にもわたるアプリのバックログがあります。

多くの内部 “アプリ” はエージェントにとって単純なウェブサイトとして扱うだけで十分に機能します。内部ウィキのようなものなら、Markdown for Agents を有効にし、Managed OAuth をオンにするだけで、エージェントは保護されたコンテンツを読むために必要なものを持つことができます。

幅広い内部アプリで基本を機能させるために、我々は Managed OAuth を使います。Access を既存のレガシー内部アプリの前に置くことで、それらを即座にエージェント対応にできます。コード変更もレトロフィットも不要で、即時の互換性を得られます。

ユーザーの代理としてのエージェント — サービスアカウントや静的トークンは不要

エージェントは組織内でユーザーを代理して行動する必要があります。最もよく見られるアンチパターンの一つは、エージェントや MCP サーバー用にサービスアカウントを発行し、静的資格情報で認証する方法です。簡単なユースケースやプロトタイプではサービストークンが使いやすく、Cloudflare Access もその用途をサポートします。しかし、細かなアクセス制御や監査ログが必要になるとサービスアカウント方式は限界を露呈します。

我々の考えでは、エージェントが行うすべての操作は、その操作を開始した人間に簡単に帰属できなければならず、エージェントはその人間が許可されている操作しか実行できるべきではありません。サービスアカウントや静的資格情報は帰属が失われるポイントになります。エージェントがすべての操作をサービスアカウント経由で洗い替えすると、confused deputy 問題に弱くなり、監査ログはエージェント自身が発信者のように見えてしまいます。

セキュリティと説明責任のために、エージェントはユーザー–エージェント関係を表現できるセキュリティ原語（セキュリティプリミティブ）を使うべきです。OAuth は第三者に対するアクセス要求と委任の業界標準プロトコルであり、エージェントがユーザーを代表して API と話すための方法を提供します。ユーザーの識別にスコープされたトークンによりアクセス制御が正しく適用され、監査ログは正しくエンドユーザーに帰属します。

標準化で解決：エージェントは RFC 9728 を web fetch ツールに実装すべき

RFC 9728 は、エージェントがどこで、どのように認証すべきかを発見できるようにする OAuth 標準です。情報の配置場所と構造を標準化します。この RFC は 2025年4月に正式化され、Model Context Protocol (MCP) によって迅速に採用されました（MCP は現在、MCP サーバーとクライアントの両方に RFC 9728 のサポートを要求しています）。

MCP の外側でも、エージェントは RFC 9728 を採用すべきです。特に重要なのは、OAuth の背後にあるウェブページや従来の REST API に対してリクエストを行うためです。

ほとんどのエージェントにはウェブページに対する基本的な HTTP リクエストを行うためのツールがあり、これを一般に “web fetch” ツールと呼びます。これは JavaScript の fetch() API に似ていて、レスポンスに対して追加の後処理を行うことがよくあります。URL をペーストしてコンテンツを取得させるような用途です。

現在、多くのエージェントの web fetch ツールは、URL が返す www-authenticate ヘッダを処理しません。モデルがレスポンスヘッダを内省して独自に対処する場合もありますが、ツール自体が www-authenticate を追跡して /.well-known/oauth-authorization-server を参照し、OAuth フローにおけるクライアントとして動作することはしていません。

しかし、ツールはそれを実行できますし、我々は強くそうあるべきだと考えています。エージェントは既にリモートの MCP クライアントとしてこれを実行しています。これを示すために、Opencode の web fetch ツールを適応させたドラフトの pull request を公開しています。

適応版ツールの動作概要:

  1. リクエスト前に既に資格情報を持っているかを確認し、あればそれを使って初回リクエストを行う
  2. もし 401 または www-authenticate ヘッダ付きの 403 を受け取った場合、ユーザーにサーバーの OAuth フローを進めるための同意を求める
  3. ユーザーが同意すると、エージェントは受け取ったトークンを用いて認証済みリクエストを行う

このフローは MCP のものと馴染みがあるはずです。もし RFC 9728 に準拠した URL をエージェントに与えると、エージェントは人間に対して認可フローを開く同意を促します。人をログインページに送り、同意ダイアログを表示し、人が承認したらエージェントはトークンで認証済みリクエストを行います。

この実装は Codex、Claude、Code、Goose などのどのエージェントでも可能で、Cloudflare 固有の仕組みを必要としません。すべて OAuth 標準に基づいて構築できます。

RFC 9728 のサポートは単なる web fetch を超えた価値があります。REST API が RFC 9728 に対応していれば、エージェントはその API に対する認証済みリクエストを自律的に開始できます。さらに REST API が RFC 9727 をサポートしていれば、クライアントは自身で REST API エンドポイントのカタログを発見でき、追加のドキュメントやエージェントスキル、MCP サーバーや CLI がなくてもより多くのことができます。

各要素はエージェントとの重要な役割を果たします。Cloudflare 自体は Cloudflare API 用の MCP サーバー（Code Mode を使って構築）、Wrangler CLI、Agent Skills、Plugin を提供していますが、RFC 9728 のサポートはそれらが事前にインストールされていない場合でもエージェントに明確な道筋を与えます。

もしエージェントがサンドボックスで信頼できないコードを実行できるなら、ユーザーが許可した API を呼ぶコードを書いて実行することもできます。我々は Cloudflare の API をエージェントが理解するのを助けるために、これをサポートする作業を進めています。

近日予定: 多数の Cloudflare アカウントにまたがる 1 つの IdP 共有

Cloudflare 内部では、同一 Organization に属する多数の Cloudflare アカウントに内部アプリをデプロイしています。Organization は、管理者が複数の Cloudflare アカウントにわたってユーザーや設定を管理し、分析を閲覧できる新しい方法です。多くの顧客と同様の課題として、各 Cloudflare アカウントは個別に IdP を設定する必要があり、Access はそのアカウントで設定された IdP を使用します。

組織全体で一貫した IdP 設定を持つことは重要です。たとえば、あるアカウントだけがワンタイムPINでサインインを許可し、別のアカウントでは SSO（シングルサインオン）を要求するといった不整合は避けたいはずです。

この問題を解決するため、我々は複数の Cloudflare アカウント間で Identity Provider を共有できるように作業しています。これにより、組織はすべてのアカウントで使用する単一の主要 IdP を指定できるようになります。組織内で新しい Cloudflare アカウントが作成されると、管理者はワンクリックで主要 IdP へのブリッジを構成でき、各アカウントの Access アプリを同一の IdP で保護できます。これにより、アカウントごとに IdP を手動で設定する必要がなくなり、多くのチームや個人がそれぞれ独自のアカウントを運用する組織でのスケーラビリティの問題を解消します。

今後の展望

企業全体で、あらゆる役割とビジネス機能の人々がエージェントを使って内部アプリを構築し、エージェントが内部アプリから文脈（コンテキスト）を取得できることを期待しています。我々はこの段階的な成長に対応するため、Workers Platform と Cloudflare One をより連携させ、Cloudflare 上で内部アプリを構築・保護するのを容易にしています。

近日中に期待できる追加項目の例:

  • Cloudflare Access と Cloudflare Workers のより直接的な統合（JWT を検証したり、どのルートに Worker が公開されているかを覚えておく必要がなくなる）
  • wrangler dev --tunnel — ローカル開発サーバーを他者に簡単に公開できる手段。新しいものを構築してデプロイ前に共有したいときに便利
  • Cloudflare Access と Cloudflare API 全体の CLI インターフェース
  • Agents Week 2026 期間中のさらなる発表

Cloudflare Access の背後にある内部アプリで Managed OAuth を有効化する

Managed OAuth は現在オープンベータとしてすべての Cloudflare 顧客が利用できます。Cloudflare ダッシュボードにアクセスして、Access アプリケーションに対して有効化してください。Workers 上で構築したアプリでも、他でホスティングされているアプリでも利用可能です。

（原文はここで途中で切れています）