← Cloudflare One / cloudflare-one / access-controls / applications

Linked App Token

Linked App Token селектор политики позволяет политике Access одного приложения принимать токены, выданные для другого приложения. Это полезно, когда одному приложению нужно выполнять аутентифицированные запросы к другому от имени пользователя, например, когда сервер MCP обращается к внутренним API или микросервис передаёт идентификатор пользователя нижестоящему сервису.

Linked App Token поддерживает два потока:

От локально размещённого к локально размещённому : Локально размещённое приложение передаёт свой Access JWT другому локально размещённому приложению. Это самый простой вариант настройки, не требующий дополнительной конфигурации OAuth.
От SaaS к локальному размещению : Приложение Access for SaaS (например, MCP-сервер с использованием OAuth) отправляет свой токен доступа OAuth самостоятельно размещённому приложению.

От локально размещённого к локально размещённому

В этом потоке приложение A является локально размещённое приложение Access которому нужно отправлять запросы к Application B, другому локально размещённому приложению Access. Когда пользователь проходит аутентификацию в Application A, Cloudflare Access передаёт JWT пользователя приложению Application A в Cf-Access-Jwt-Assertion заголовок. Затем приложение A может передать этот токен приложению B в Cf-Access-Token заголовок. Access проверит токен по правилу Linked App Token в политике приложения B и разрешит запрос, если токен был выдан для приложения A.

flowchart LR
accTitle: Self-hosted to self-hosted linked app token flow
    User --> appA["Application A <br> (self-hosted)"]
    appA -- "Cf-Access-Token: &lt;JWT&gt;" --> appB["Application B <br> (self-hosted)"]
    idp[Identity provider] <--> appA

Предварительные требования

Two локально размещённые приложения Access

1. Создайте политику Linked App Token

Создайте политику для приложения B (нижестоящего приложения, которое будет получать перенаправленные запросы):

В Панель управления Cloudflare ↗, перейдите в Zero Trust > Контроль доступа > Приложения.
Выберите Application B и выберите Изменить.
Перейдите в Политики и выберите Создать новую политику.
Настройте политику Действие к Service Auth.

Примечание
Примечание
Селектор Linked App Token работает только с Service Auth действие, аналогично правилам токена службы.
Для Селектор, выберите Linked App Token.
Для Значение, выберите приложение A. Например,

Действие Тип правила Селектор Значение

Service Auth Включить Linked App Token application-a
Сохраните политику.
В Application B добавьте политику в Политики доступа список.
Сохраните приложение.

Действие	Тип правила	Селектор	Значение
Service Auth	Включить	Linked App Token	`application-a`

Получите uid приложения Application A:
Необходимые разрешения API-токена

Хотя бы одно из следующих права доступа токена требуется:
- Access: Apps and Policies Revoke
- Access: Apps and Policies Write
- Access: Apps and Policies Read
List Access applications
```
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 значение на uid приложения Application A:
Необходимые разрешения API-токена

Хотя бы одно из следующих права доступа токена требуется:
- Access: Apps and Policies Write
Создать многократно используемую политику Access
```
curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/policies" \
	--request POST \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"name": "Allow requests from Application A",
		"decision": "non_identity",
		"include": [
				{
						"linked_app_token": {
								"app_uid": "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
						}
				}
		]
	}'
```
Примечание
Примечание
linked_app_token тип правила работает только с non_identity решения, аналогично правилам токена службы.

2. Перенаправьте Access JWT

Когда Cloudflare Access аутентифицирует пользователя для приложения A, он отправляет подписанный JWT в Cf-Access-Jwt-Assertion заголовок запроса. Приложение A должно переслать этот токен приложению B в Cf-Access-Token заголовок:

Cf-Access-Token: <JWT from Cf-Access-Jwt-Assertion>

Когда Access получает запрос к приложению B, происходит следующее:

Извлеките токен из Cf-Access-Token заголовок.
Проверьте, что токен был выпущен для Application A (совпадает с app_uid в правиле Linked App Token).
Если он действителен, Access выдает новый Cf-Access-Jwt-Assertion с ограничением по тегу AUD приложения B, перенаправляет его на источник приложения B и связывает запрос в журнале аудита с исходным пользователем.

От SaaS к локальному размещению

В этом примере Приложение Access for SaaS (например, MCP-сервер, который реализует OAuth ↗) должно отправлять запросы к локально размещённому приложению Access. Приложение SaaS получает токен доступа OAuth от Cloudflare Access и передаёт его локально размещённому приложению в Authorization: Bearer заголовок.

flowchart LR
accTitle: SaaS to self-hosted linked app token flow
    User --> appA["Application A <br> (Access for SaaS)"]
    appA -- "Authorization: Bearer &lt;token&gt;" --> appB["Application B <br> (self-hosted)"]
    idp[Identity provider] <--> appA

Предварительные требования

1. Создайте политику Linked App Token

Создайте политику для Self-hosted приложения (приложения B):

В Панель управления Cloudflare ↗, перейдите в Zero Trust > Контроль доступа > Приложения.
Выберите локально размещённое приложение (Application B) и нажмите Изменить.
Перейдите в Политики и выберите Создать новую политику.
Настройте политику Действие к Service Auth.

Примечание
Примечание
Селектор Linked App Token работает только с Service Auth действие, аналогично правилам токена службы.
Для Селектор, выберите Linked App Token.
Для Значение, выберите приложение Access for SaaS (приложение A). Например,

Действие Тип правила Селектор Значение

Service Auth Включить Linked App Token application-a
Сохраните политику.
В локально размещённом приложении (приложение B) добавьте политику в Политики доступа список.
Сохраните приложение.

Действие	Тип правила	Селектор	Значение
Service Auth	Включить	Linked App Token	`application-a`

Получите uid приложения Access для SaaS (Application A):
Необходимые разрешения API-токена

Хотя бы одно из следующих права доступа токена требуется:
- Access: Apps and Policies Revoke
- Access: Apps and Policies Write
- Access: Apps and Policies Read
List Access applications
```
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 значение на uid приложения Access для SaaS (Application A):
Необходимые разрешения API-токена

Хотя бы одно из следующих права доступа токена требуется:
- Access: Apps and Policies Write
Создать многократно используемую политику Access
```
curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/policies" \
	--request POST \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"name": "Allow requests from SaaS app",
		"decision": "non_identity",
		"include": [
				{
						"linked_app_token": {
								"app_uid": "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
						}
				}
		]
	}'
```
Примечание
Примечание
linked_app_token тип правила работает только с non_identity решения, аналогично правилам токена службы.

2. Настройте пересылку токенов

Приложение SaaS должно перенаправлять OAuth access_token к self-hosted-приложению в заголовке HTTP:

Authorization: Bearer ACCESS_TOKEN

Сквозной процесс выглядит следующим образом:

Пользователь проходит аутентификацию в приложении Access for SaaS через OAuth.
В случае успеха приложение получает access_token.
Приложение отправляет запрос к локально размещенному приложению с токеном в Authorization: Bearer заголовок.
Cloudflare Access проверяет токен и сверяет его с linked_app_token правило. Если сертификат действителен, запрос разрешается.

Известные ограничения

Политику Linked App Token можно добавить только к локально размещённые приложения. Его нельзя добавить в Приложения SaaS или другие типы приложений.
Эта функция лучше всего работает с приложениями, которые используют Cloudflare Access JWT для аутентификации и идентификации. Если нижестоящее приложение реализует собственный уровень аутентификации после Cloudflare Access, запросы, прошедшие проверку Access, все равно могут быть отклонены самим приложением.
Если вышестоящее приложение использует Managed OAuth, клиент получает непрозрачный токен доступа, а не JWT. Клиент не может напрямую передавать этот токен нижестоящим приложениям в качестве Cf-Access-Token заголовок. Вместо этого исходный сервер вышестоящего приложения должен считывать Cf-Access-Jwt-Assertion заголовок (который содержит разрешенный JWT) и передает его как Cf-Access-Token к нижестоящему приложению. Если вы хотите, чтобы клиенты обращались к нескольким конечным точкам без прокси, рассмотрите возможность использования многодоменное приложение Access взамен.