Linked App Token ポリシーセレクターを使うと、あるアプリケーションの Access ポリシーで、別のアプリケーション向けに発行されたトークンを受け入れられます。あるアプリケーションがユーザーの代わりに、別のアプリケーションへ認証済みリクエストを送るときに便利です。たとえば、MCP サーバーが社内 API を呼び出す場合や、マイクロサービスがユーザー ID をダウンストリームサービスへ転送する場合です。
Linked App Token は次の 2 つのフローに対応しています。
- セルフホストからセルフホスト — セルフホストアプリケーションが、自身の Access JWT を別のセルフホストアプリケーションへ転送します。いちばんシンプルな構成で、追加の OAuth 設定は不要です。
- SaaS からセルフホスト — Access for SaaS アプリケーション(OAuth を使う MCP サーバー など)が、OAuth のアクセストークンをセルフホストアプリケーションへ送ります。
このフローでは、Application A は セルフホスト Access アプリケーション で、別のセルフホスト Access アプリケーションである Application B へリクエストを送ります。ユーザーが Application A に認証すると、Cloudflare Access はユーザーの JWT を Cf-Access-Jwt-Assertion ヘッダーで Application A に送ります。Application A はそのトークンを Cf-Access-Token ヘッダーで Application B へ転送できます。Access は Application B のポリシーにある Linked App Token ルールに対してトークンを検証し、トークンが Application A 向けに発行されていればリクエストを許可します。
flowchart LR
accTitle: セルフホストからセルフホストへの Linked App Token フロー
User[ユーザー] --> appA["Application A <br> (セルフホスト)"]
appA -- "Cf-Access-Token: <JWT>" --> appB["Application B <br> (セルフホスト)"]
idp[ID プロバイダー] <--> appA
- セルフホスト Access アプリケーション が 2 つあること
転送されたリクエストを受け取るダウンストリームアプリケーション(Application B)にポリシーを作成します。
-
Cloudflare ダッシュボード ↗ で、Zero Trust > Access controls > Applications を開きます。
-
Application B を選び、Edit を選びます。
-
Policies タブを開き、Create new policy を選びます。
-
ポリシーの Action を Service Auth に設定します。
-
Selector で Linked App Token を選びます。
-
Value で Application A を選びます。例:
アクション ルールタイプ セレクター 値 Service Auth Include Linked App Token application-a -
ポリシーを保存します。
-
Application B で、ポリシーを Access policies リストに追加します。
-
アプリケーションを保存します。
-
Application A の
uidを取得します。
At least one of the following token permissions is required:Required API token permissions
Access: Apps and Policies RevokeAccess: Apps and Policies WriteAccess: Apps and Policies Read
List Access applicationsbash curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/apps" \ --request GET \ --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN"{ "id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890", "uid": "a1b2c3d4-e5f6-7890-abcd-ef1234567890", "type": "self_hosted", "name": "application-a", ... } -
ダウンストリームアプリケーションに Access ポリシーを作成し、
app_uidの値を Application A のuidに置き換えます。
At least one of the following token permissions is required:Required API token permissions
Access: Apps and Policies Write
Create an Access reusable policybash curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/policies" \ --request POST \ --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \ --json '{ "name": "Application A からのリクエストを許可", "decision": "non_identity", "include": [ { "linked_app_token": { "app_uid": "a1b2c3d4-e5f6-7890-abcd-ef1234567890" } } ] }'
Cloudflare Access がユーザーを Application A に認証すると、署名済み JWT を Cf-Access-Jwt-Assertion リクエストヘッダーで送ります。Application A はこのトークンを Cf-Access-Token ヘッダーで Application B へ転送する必要があります。
Cf-Access-Token: <JWT from Cf-Access-Jwt-Assertion>Access が Application B へのリクエストを受け取ると、次の処理を行います。
Cf-Access-Tokenヘッダーからトークンを取り出します。- トークンが Application A 向けに発行されたことを検証します(Linked App Token ルールの
app_uidと一致すること)。 - 有効な場合、Access は Application B の AUD タグにスコープした新しい
Cf-Access-Jwt-Assertionを発行し、Application B のオリジンへ転送します。監査ログでは、リクエストは元のユーザーに紐づけられます。
この例では、Access for SaaS アプリケーション(OAuth ↗ を実装する MCP サーバーなど)が、セルフホスト Access アプリケーションへリクエストを送ります。SaaS アプリは Cloudflare Access から OAuth のアクセストークンを取得し、Authorization: Bearer ヘッダーでセルフホストアプリケーションへ送ります。
flowchart LR
accTitle: SaaS からセルフホストへの Linked App Token フロー
User[ユーザー] --> appA["Application A <br> (Access for SaaS)"]
appA -- "Authorization: Bearer <token>" --> appB["Application B <br> (セルフホスト)"]
idp[ID プロバイダー] <--> appA
セルフホストアプリケーション(Application B)にポリシーを作成します。
-
Cloudflare ダッシュボード ↗ で、Zero Trust > Access controls > Applications を開きます。
-
セルフホストアプリ(Application B) を選び、Edit を選びます。
-
Policies タブを開き、Create new policy を選びます。
-
ポリシーの Action を Service Auth に設定します。
-
Selector で Linked App Token を選びます。
-
Value で Access for SaaS アプリ(Application A) を選びます。例:
アクション ルールタイプ セレクター 値 Service Auth Include Linked App Token application-a -
ポリシーを保存します。
-
セルフホストアプリ(Application B) で、ポリシーを Access policies リストに追加します。
-
アプリケーションを保存します。
-
Access for SaaS アプリ(Application A) の
uidを取得します。
At least one of the following token permissions is required:Required API token permissions
Access: Apps and Policies RevokeAccess: Apps and Policies WriteAccess: Apps and Policies Read
List Access applicationsbash curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/apps" \ --request GET \ --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN"{ "id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890", "uid": "a1b2c3d4-e5f6-7890-abcd-ef1234567890", "type": "saas", "name": "my-saas-app", ... } -
ダウンストリームアプリケーションに Access ポリシーを作成し、
app_uidの値を Access for SaaS アプリ(Application A) のuidに置き換えます。
At least one of the following token permissions is required:Required API token permissions
Access: Apps and Policies Write
Create an Access reusable policybash curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/policies" \ --request POST \ --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \ --json '{ "name": "SaaS アプリからのリクエストを許可", "decision": "non_identity", "include": [ { "linked_app_token": { "app_uid": "a1b2c3d4-e5f6-7890-abcd-ef1234567890" } } ] }'
SaaS アプリケーションは、OAuth の access_token を HTTP ヘッダーでセルフホストアプリケーションへ転送する必要があります。
Authorization: Bearer ACCESS_TOKENエンドツーエンドの流れは次のとおりです。
- ユーザーは OAuth 経由で Access for SaaS アプリに対して認証します。
- 成功すると、アプリケーションは
access_tokenを受け取ります。 - アプリケーションは、
Authorization: Bearerヘッダーにトークンを付けてセルフホストアプリケーションへリクエストを送ります。 - Cloudflare Access はトークンを検査し、
linked_app_tokenルールに照合して検証します。有効ならリクエストを許可します。
- Linked App Token ポリシーは セルフホストアプリケーション にのみ追加できます。SaaS アプリケーション やほかのアプリケーション種類には追加できません。
- この機能は、認証と ID に Cloudflare Access JWT を使うアプリケーションで最もよく動作します。ダウンストリームアプリケーションが Cloudflare Access のあとに独自の認証層を実装している場合、Access の検証を通過したリクエストでも、アプリケーション側で拒否されることがあります。
- 上流アプリケーションが Managed OAuth を使う場合、クライアントが受け取るのは JWT ではなく 不透明なアクセストークン です。クライアントはこのトークンを
Cf-Access-Tokenヘッダーとしてダウンストリームアプリケーションへ直接転送できません。代わりに、上流アプリケーションのオリジンがCf-Access-Jwt-Assertionヘッダー(解決済み JWT を含む)を読み取り、Cf-Access-Tokenとしてダウンストリームアプリケーションへ転送する必要があります。プロキシなしでクライアントから複数のエンドポイントへアクセスしたい場合は、代わりに マルチドメイン Access アプリケーション を検討してください。