Cloudflare Access でアプリケーションを保護すると、デフォルトでは CLI、AI エージェント、SDK、スクリプトなどのブラウザー以外のクライアントは、ブラウザーベースのログインリダイレクトを完了できません。使えるトークンや認可エンドポイントのない 302 リダイレクトを受け取ります。
Managed OAuth は、Access をアプリケーション向けの標準 OAuth 2.0 認可サーバーにすることで、この問題を解決します。Access はブラウザーログインと同じポリシーを適用し、オリジン側の見え方は変わりません。
- セルフホストの Access アプリケーション、MCP サーバーアプリケーション、または MCP サーバーポータル
- RFC 8707 ↗ に対応する OAuth クライアント
- Cloudflare ダッシュボード ↗ で、Zero Trust > Access controls > Applications を開きます。
- 設定するアプリケーションを探し、右側の三点リーダー > Edit を選択します。
- Advanced settings タブを開き、Managed OAuth をオンにします。
- (任意)Managed OAuth の設定 を構成します。
- Save を選択します。
-
既存の Access アプリケーション設定を取得します。
At least one of the following token permissions is required:Required API token permissions
Access: Apps and Policies WriteAccess: 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" -
PUTリクエストを送り、oauth_configuration.enabledをtrueに設定します。既存の設定を上書きしないよう、リクエスト本文には直前のGETリクエストで返されたすべてのフィールドを含めてください。
At least one of the following token permissions is required:Required API token permissions
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 へのログインを求めます。詳細は 認可フロー を参照してください。
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 を有効にしないでください。
- Cloudflare ダッシュボード ↗ で、Zero Trust > Access controls > Applications を開きます。
- 設定する MCP サーバーアプリケーションを探し、右側の三点リーダー > Edit を選択します。
- Advanced settings タブを開き、Managed OAuth をオンにします。
- (任意)Managed OAuth の設定 を構成します。
- Save を選択します。
-
既存の Access アプリケーション設定を取得します。
At least one of the following token permissions is required:Required API token permissions
Access: Apps and Policies WriteAccess: 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" -
PUTリクエストを送り、oauth_configuration.enabledをtrueに設定します。既存の設定を上書きしないよう、リクエスト本文には直前のGETリクエストで返されたすべてのフィールドを含めてください。
At least one of the following token permissions is required:Required API token permissions
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 クライアントがブラウザー cookie フローなしでポータル経由のユーザー認証を行う仕組みです。
- Cloudflare ダッシュボード ↗ で、Zero Trust > Access controls > AI controls を開きます。
- 設定するポータルを探し、右側の三点リーダー > Edit を選択します。
- Advanced settings タブを開き、Managed OAuth をオンにします。
- (任意)Managed OAuth の設定 を構成します。
- Save を選択します。
-
ポータルの基盤となる Access アプリケーションの既存設定を取得します。
At least one of the following token permissions is required:Required API token permissions
Access: Apps and Policies WriteAccess: 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" -
PUTリクエストを送り、oauth_configuration.enabledをtrueに設定します。既存の設定を上書きしないよう、リクエスト本文には直前のGETリクエストで返されたすべてのフィールドを含めてください。
At least one of the following token permissions is required:Required API token permissions
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 サーバーアプリケーション、または 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 |
-
既存の Access アプリケーション設定を取得します。
At least one of the following token permissions is required:Required API token permissions
Access: Apps and Policies WriteAccess: 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" -
Managed OAuth の設定を含めて
PUTリクエストを送ります。既存の設定を上書きしないよう、リクエスト本文には直前のGETリクエストで返されたすべてのフィールドを含めてください。
At least one of the following token permissions is required:Required API token permissions
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 ヘッダーが含まれます。
認可フローは次のとおりです。
-
クライアントは
/.well-known/エンドポイントから OAuth 認可サーバーのメタデータを取得します。https://<your-app-domain>/.well-known/oauth-authorization-serverこのエンドポイントは RFC 8414 ↗ と RFC 9728 ↗ に準拠し、アプリケーションの認可エンドポイントとトークンエンドポイントの URL を返します。
-
クライアントは認可コードフローを開始します。ユーザーのブラウザーを Access の認可エンドポイントへ開き、ユーザーは通常どおり IdP にログインします。
-
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 と サービストークン は、どちらもブラウザー以外のクライアントが Access で保護されたアプリケーションに認証できるようにしますが、用途が異なります。
| Managed OAuth | サービストークン | |
|---|---|---|
| 認証モデル | ユーザーベース。エンドユーザーがアイデンティティプロバイダー経由でログインします | マシンベース。共有シークレットがサービス自体を認証します |
| 向いている用途 | 人がリクエストを開始する対話型 CLI ツール、AI エージェント、SDK | 完全に自動化されたシステム、cron ジョブ、CI/CD パイプライン、サーバー間通信 |
| ユーザー ID | どのユーザーがリクエストしたかを Access が把握します | ユーザー ID はありません。リクエストはサービストークンに帰属します |
| ポリシーの適用 | ID ベースのポリシーを使えます(特定のグループやメールを必須にするなど) | Service Auth ポリシーアクションが必要です |
| 認証情報の管理 | 配布する共有シークレットはありません。ユーザーは自身の認証情報で認証します | Client ID と Client Secret の配布とローテーションが必要です |
ブラウザー以外のクライアントに、ブラウザーと同じ方法でユーザーを認証させたい場合は Managed OAuth を使います。ユーザーは一度ログインし、クライアントはその代理でリクエストするための OAuth トークンを受け取ります。
人が関与せず、マシン ID でアプリケーションへプログラムからアクセスする必要がある場合は、サービストークンを使います。