Skip to content

非公式本サイトは非公式の日本語ドキュメントであり、Cloudflare 公式サイトではありません。最新情報はdevelopers.cloudflare.comをご確認ください。

Managed OAuth

最終更新 Markdown で表示Agent セットアップ

Cloudflare Access でアプリケーションを保護すると、デフォルトでは CLI、AI エージェント、SDK、スクリプトなどのブラウザー以外のクライアントは、ブラウザーベースのログインリダイレクトを完了できません。使えるトークンや認可エンドポイントのない 302 リダイレクトを受け取ります。

Managed OAuth は、Access をアプリケーション向けの標準 OAuth 2.0 認可サーバーにすることで、この問題を解決します。Access はブラウザーログインと同じポリシーを適用し、オリジン側の見え方は変わりません。

前提条件

セルフホストアプリケーションで Managed OAuth を有効にする

  1. Cloudflare ダッシュボード で、Zero Trust > Access controls > Applications を開きます。
  2. 設定するアプリケーションを探し、右側の三点リーダー > Edit を選択します。
  3. Advanced settings タブを開き、Managed OAuth をオンにします。
  4. (任意)Managed OAuth の設定 を構成します。
  5. Save を選択します。
  1. 既存の Access アプリケーション設定を取得します。

    Required API token permissions

    At least one of the following token permissions is required:
    • Access: Apps and Policies Write
    • Access: Apps and Policies Read
    Get an Access applicationbash
    curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/apps/$APP_ID" \
    	--request GET \
    	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN"
  2. PUT リクエストを送り、oauth_configuration.enabledtrue に設定します。既存の設定を上書きしないよう、リクエスト本文には直前の GET リクエストで返されたすべてのフィールドを含めてください。

    Required API token permissions

    At least one of the following token permissions is required:
    • Access: Apps and Policies Write
    Update an Access applicationbash
    curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/apps/$APP_ID" \
    	--request PUT \
    	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
    	--json '{
    		"oauth_configuration": {
    				"enabled": true
    		}
    	}'

テストするには、RFC 8707 対応の OAuth クライアントを開き、アプリケーションへリクエストを送ります。クライアントはブラウザーウィンドウを開き、Access へのログインを求めます。詳細は 認可フロー を参照してください。

MCP サーバーアプリケーションで Managed OAuth を有効にする

Managed OAuth は MCP サーバーアプリケーション で利用でき、MCP クライアントが標準の OAuth 2.0 フローで Access 経由のユーザー認証を行えます。Zero Trust 組織と同じアカウントで Cloudflare 経由で提供する MCP サーバーに、このフローを使います。MCP サーバーは Cf-Access-Jwt-Assertion ヘッダーで送られる Access JWT を検証する必要があります。

独自の OAuth フローをすでに処理しており、Access JWT を検証できないサードパーティ製 MCP サーバーコードには、Managed OAuth を有効にしないでください。

  1. Cloudflare ダッシュボード で、Zero Trust > Access controls > Applications を開きます。
  2. 設定する MCP サーバーアプリケーションを探し、右側の三点リーダー > Edit を選択します。
  3. Advanced settings タブを開き、Managed OAuth をオンにします。
  4. (任意)Managed OAuth の設定 を構成します。
  5. Save を選択します。
  1. 既存の Access アプリケーション設定を取得します。

    Required API token permissions

    At least one of the following token permissions is required:
    • Access: Apps and Policies Write
    • Access: Apps and Policies Read
    Get an Access applicationbash
    curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/apps/$APP_ID" \
    	--request GET \
    	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN"
  2. PUT リクエストを送り、oauth_configuration.enabledtrue に設定します。既存の設定を上書きしないよう、リクエスト本文には直前の GET リクエストで返されたすべてのフィールドを含めてください。

    Required API token permissions

    At least one of the following token permissions is required:
    • Access: Apps and Policies Write
    Update an Access applicationbash
    curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/apps/$APP_ID" \
    	--request PUT \
    	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
    	--json '{
    		"oauth_configuration": {
    				"enabled": true
    		}
    	}'

テストするには、MCP クライアントを開き、保護された MCP サーバーに接続します。クライアントはブラウザーウィンドウを開き、Access へのログインを求めます。詳細は 認可フロー を参照してください。

MCP サーバーポータルで Managed OAuth を有効にする

Managed OAuth は MCP サーバーポータル で利用でき、MCP クライアントがブラウザー cookie フローなしでポータル経由のユーザー認証を行う仕組みです。

  1. Cloudflare ダッシュボード で、Zero Trust > Access controls > AI controls を開きます。
  2. 設定するポータルを探し、右側の三点リーダー > Edit を選択します。
  3. Advanced settings タブを開き、Managed OAuth をオンにします。
  4. (任意)Managed OAuth の設定 を構成します。
  5. Save を選択します。
  1. ポータルの基盤となる Access アプリケーションの既存設定を取得します。

    Required API token permissions

    At least one of the following token permissions is required:
    • Access: Apps and Policies Write
    • Access: Apps and Policies Read
    Get an Access applicationbash
    curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/apps/$APP_ID" \
    	--request GET \
    	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN"
  2. PUT リクエストを送り、oauth_configuration.enabledtrue に設定します。既存の設定を上書きしないよう、リクエスト本文には直前の GET リクエストで返されたすべてのフィールドを含めてください。

    Required API token permissions

    At least one of the following token permissions is required:
    • Access: Apps and Policies Write
    Update an Access applicationbash
    curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/apps/$APP_ID" \
    	--request PUT \
    	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
    	--json '{
    		"oauth_configuration": {
    				"enabled": true
    		}
    	}'

テストするには、MCP クライアントを開き、MCP ポータルに接続 します。クライアントはブラウザーウィンドウを開き、Access へのログインを求めます。詳細は 認可フロー を参照してください。

Managed OAuth の設定

これらの設定は、セルフホストアプリMCP サーバーアプリケーション、または MCP サーバーポータルAdvanced settings タブで構成します。

  • Allow localhost clients: localhost 上のリダイレクト URI を持つ任意のクライアントを許可します。
  • Allow loopback clients: 127.0.0.1 上のリダイレクト URI を持つ任意のクライアントを許可します。
  • Allowed redirect URIs: 動的登録クライアントに許可するリダイレクト URI(例: https://playground.ai.cloudflare.com/*)。URL は https である必要があります。パスの末尾を /* にすると、すべてのサブパスに一致します。
  • Grant session duration: OAuth リフレッシュトークンが有効な期間です。
  • Access token lifetime: OIDC アクセストークンをアプリケーションの認証に使える期間です。短い Access token lifetime(デフォルト 15 分)と、より長い Grant session duration を組み合わせることを Cloudflare は推奨します。アクセストークンの期限が切れると、Cloudflare はリフレッシュトークンを使い、ユーザーを Access ポリシーに照らして再評価したうえで新しいトークンを発行します。リフレッシュトークンの期限が切れると、ユーザーはアイデンティティプロバイダーで再認証する必要があります。

これらの設定は、Access applications エンドポイントの oauth_configuration オブジェクトで構成します。

ダッシュボードの設定 API フィールド
Allow localhost clients dynamic_client_registration.allow_any_on_localhost
Allow loopback clients dynamic_client_registration.allow_any_on_loopback
Allowed redirect URIs dynamic_client_registration.allowed_uris
Grant session duration grant.session_duration
Access token lifetime grant.access_token_lifetime
  1. 既存の Access アプリケーション設定を取得します。

    Required API token permissions

    At least one of the following token permissions is required:
    • Access: Apps and Policies Write
    • Access: Apps and Policies Read
    Get an Access applicationbash
    curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/apps/$APP_ID" \
    	--request GET \
    	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN"
  2. Managed OAuth の設定を含めて PUT リクエストを送ります。既存の設定を上書きしないよう、リクエスト本文には直前の GET リクエストで返されたすべてのフィールドを含めてください。

    Required API token permissions

    At least one of the following token permissions is required:
    • Access: Apps and Policies Write
    Update an Access applicationbash
    curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/apps/$APP_ID" \
    	--request PUT \
    	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
    	--json '{
    		"oauth_configuration": {
    				"enabled": true,
    				"dynamic_client_registration": {
    						"enabled": true,
    						"allow_any_on_localhost": true,
    						"allow_any_on_loopback": true,
    						"allowed_uris": [
    								"https://playground.ai.cloudflare.com/*"
    						]
    				},
    				"grant": {
    						"access_token_lifetime": "5m",
    						"session_duration": "24h"
    				}
    		}
    	}'

認可フロー

Managed OAuth が有効な場合、Access はブラウザー以外のクライアントに対して 302 リダイレクトではなく 401 レスポンスを返します。この 401 には、クライアントを Access の OAuth ディスカバリーメタデータへ誘導する WWW-Authenticate ヘッダーが含まれます。

認可フローは次のとおりです。

  1. クライアントは /.well-known/ エンドポイントから OAuth 認可サーバーのメタデータを取得します。

    https://<your-app-domain>/.well-known/oauth-authorization-server

    このエンドポイントは RFC 8414RFC 9728 に準拠し、アプリケーションの認可エンドポイントとトークンエンドポイントの URL を返します。

  2. クライアントは認可コードフローを開始します。ユーザーのブラウザーを Access の認可エンドポイントへ開き、ユーザーは通常どおり IdP にログインします。

  3. Access はクライアントに OAuth アクセストークンを発行します。クライアントは以降の保護対象アプリケーションへのリクエストで、このトークンを使います。

トークン形式

Managed OAuth が発行するのは 不透明な(opaque)アクセストークン(例: oauth:CvNoo...)であり、JSON Web Token(JWT)ではありません。これは意図した設計です。OAuth フローにより、クライアントはユーザーの代理でリクエストできますが、ID 情報はクライアントに公開されません。

クライアントがアプリケーションに不透明トークンを提示すると、Cloudflare はバックエンドでトークンをユーザー ID に解決し、署名済みアサーションをオリジンへ転送します。オリジンから見ると、リクエストはブラウザー認証のリクエストと同じです。

トークンは不透明なため、クライアントはデコードしたり、ほかのアプリケーションへ JWT として直接転送したりできません。下流の Access アプリケーションへ認証済みリクエストを送るには、Linked App Token パターンを使います。オリジンは Cf-Access-Jwt-Assertion ヘッダーを読み取り、下流アプリへ Cf-Access-Token として転送します。

マルチドメインアプリケーション

Access アプリケーションに 複数のドメイン が設定されている場合、いずれか 1 つのドメイン経由で取得した OAuth トークンは、同じアプリケーション内のすべてのドメインで有効です。ユーザーは一度認証すれば、追加のプロンプトなしで同じトークンを使ってすべてのドメインにアクセスできます。

共通の信頼境界を共有する複数の内部サービスがある場合に便利です。Linked App Token ポリシーを持つ Access アプリケーションを個別に設定する代わりに、すべてのドメインを 1 つのアプリケーションに追加し、Managed OAuth で一度認証できます。

Managed OAuth とサービストークンの比較

Managed OAuth と サービストークン は、どちらもブラウザー以外のクライアントが Access で保護されたアプリケーションに認証できるようにしますが、用途が異なります。

Managed OAuth サービストークン
認証モデル ユーザーベース。エンドユーザーがアイデンティティプロバイダー経由でログインします マシンベース。共有シークレットがサービス自体を認証します
向いている用途 人がリクエストを開始する対話型 CLI ツール、AI エージェント、SDK 完全に自動化されたシステム、cron ジョブ、CI/CD パイプライン、サーバー間通信
ユーザー ID どのユーザーがリクエストしたかを Access が把握します ユーザー ID はありません。リクエストはサービストークンに帰属します
ポリシーの適用 ID ベースのポリシーを使えます(特定のグループやメールを必須にするなど) Service Auth ポリシーアクションが必要です
認証情報の管理 配布する共有シークレットはありません。ユーザーは自身の認証情報で認証します Client ID と Client Secret の配布とローテーションが必要です

ブラウザー以外のクライアントに、ブラウザーと同じ方法でユーザーを認証させたい場合は Managed OAuth を使います。ユーザーは一度ログインし、クライアントはその代理でリクエストするための OAuth トークンを受け取ります。

人が関与せず、マシン ID でアプリケーションへプログラムからアクセスする必要がある場合は、サービストークンを使います。

役に立ちましたか?