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

Managed OAuth

Когда вы защищаете приложение с помощью Cloudflare Access, по умолчанию клиенты без браузера (например, CLI, ИИ-агенты, SDK и скрипты) не могут пройти перенаправление для входа через браузер. Вместо этого они получают 302 редирект без пригодного для использования токена или конечной точки авторизации.

Managed OAuth решает эту задачу, превращая Access в стандартный сервер авторизации OAuth 2.0 для вашего приложения. Access применяет те же политики, что и вход через браузер, и ваш origin не заметит никакой разницы.

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

A локально размещённое приложение Access, приложение MCP-сервера, или Портал MCP-сервера
Клиент OAuth, который поддерживает RFC 8707 ↗

Включите управляемый OAuth для локально размещённого приложения

В Панель управления Cloudflare ↗, перейдите в Zero Trust > Контроль доступа > Приложения.
Найдите приложение, которое вы хотите настроить, а затем выберите три точки справа > Изменить.
Перейдите в Расширенные настройки вкладку и включите Managed OAuth.
(Необязательно) Настройте Настройки Managed OAuth.
Выберите Save.

Получите текущую конфигурацию приложения Access:
Необходимые разрешения API-токена

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

Хотя бы одно из следующих права доступа токена требуется:
- Access: Apps and Policies Write
Обновление приложения Access
```
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
		}
	}'
```

Чтобы протестировать, откройте OAuth-клиент, совместимый с RFC 8707, и отправьте запрос к своему приложению. Клиент должен открыть окно браузера с предложением войти в Access. См. Поток авторизации раздел, чтобы узнать больше.

Включите управляемый OAuth для приложения MCP-сервера

Managed OAuth доступен на приложения MCP-сервера и позволяет клиентам MCP аутентифицировать пользователей через Access с помощью стандартного потока OAuth 2.0. Используйте этот поток для серверов MCP, которые обслуживаются через Cloudflare в той же учетной записи, что и ваша организация Zero Trust. Сервер MCP должен проверять JWT токен Access, отправленный в Cf-Access-Jwt-Assertion заголовок.

Не включайте Managed OAuth для стороннего кода сервера MCP, который уже самостоятельно обрабатывает поток OAuth и не может проверять JWT Access.

В Панель управления Cloudflare ↗, перейдите в Zero Trust > Контроль доступа > Приложения.
Найдите приложение MCP-сервера, которое вы хотите настроить, а затем выберите три точки справа > Изменить.
Перейдите в Расширенные настройки вкладку и включите Managed OAuth.
(Необязательно) Настройте Настройки Managed OAuth.
Выберите Save.

Получите текущую конфигурацию приложения Access:
Необходимые разрешения API-токена

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

Хотя бы одно из следующих права доступа токена требуется:
- Access: Apps and Policies Write
Обновление приложения Access
```
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. См. Поток авторизации раздел, чтобы узнать больше.

Включите управляемый OAuth для портала MCP-сервера

Managed OAuth доступен на порталы MCP-сервера и представляет собой механизм, который позволяет клиентам MCP аутентифицировать пользователей через портал без использования файлов cookie браузера.

В Панель управления Cloudflare ↗, перейдите в Zero Trust > Контроль доступа > Элементы управления ИИ.
Найдите портал, который вы хотите настроить, а затем выберите три точки справа > Изменить.
Перейдите в Расширенные настройки вкладке включите Managed OAuth.
(Необязательно) Настройте Настройки Managed OAuth.
Выберите Save.

Получите текущую конфигурацию базового приложения Access для портала:
Необходимые разрешения API-токена

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

Хотя бы одно из следующих права доступа токена требуется:
- Access: Apps and Policies Write
Обновление приложения Access
```
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 portal. Клиент должен открыть окно браузера с запросом на вход в Access. См. Поток авторизации раздел, чтобы узнать больше.

Настройки Managed OAuth

Настройте эти параметры в Расширенные настройки вкладке вашего локально размещённое приложение, приложение MCP-сервера, или Портал MCP-сервера.

Разрешить клиентов localhost: Разрешить любому клиенту с redirect URI на localhost.
Разрешить клиентов loopback: Разрешить любому клиенту с redirect URI на 127.0.0.1.
Разрешённые URI перенаправления: Разрешенные URI перенаправления для динамически зарегистрированных клиентов (например, https://playground.ai.cloudflare.com/*). URL должен использовать https. Пути могут заканчиваться на /* чтобы соответствовать всем вложенным путям.
Длительность сессии предоставления доступа: Как долго действителен токен обновления OAuth.
Время жизни токена доступа: Как долго OIDC-токен Access можно использовать для аутентификации в вашем приложении. Cloudflare рекомендует настроить короткий Время жизни токена доступа (по умолчанию 15 минут) в сочетании с более длительным Длительность сессии предоставления доступа. Когда истекает срок действия токена доступа, Cloudflare использует токен обновления, чтобы выдать новый токен после повторной проверки пользователя на соответствие вашим политикам Access. Когда истекает срок действия токена обновления, пользователь должен повторно пройти аутентификацию у поставщика идентификации.

Рекомендуемая конфигурация для сценариев использования CLI и агента

Для CLI-инструментов, ИИ-агентов и других клиентов без браузера задайте короткий срок действия токена доступа (5-15 минут) при более длительной сессии выдачи (1-2 недели). При такой конфигурации:

Клиент незаметно обновляет токены в фоновом режиме с помощью токена обновления: взаимодействие с пользователем не требуется.
Политики Access повторно проверяются при каждом обновлении токена, что обеспечивает непрерывную проверку личности.
Пользователь видит запрос на авторизацию только тогда, когда истекает сессия предоставления доступа (refresh-токен).

Например, при токене доступа со сроком действия 15 минут и сессии предоставления доступа сроком на 2 недели пользователь проходит аутентификацию через браузер один раз, а затем работает без прерываний до двух недель, прежде чем потребуется повторная аутентификация.

Настройте эти параметры через oauth_configuration объект в Приложения Access конечная точка.

Настройка в панели управления	Поле API
Разрешить клиентов localhost	`dynamic_client_registration.allow_any_on_localhost`
Разрешить клиентов loopback	`dynamic_client_registration.allow_any_on_loopback`
Разрешённые URI перенаправления	`dynamic_client_registration.allowed_uris`
Длительность сессии предоставления доступа	`grant.session_duration`
Время жизни токена доступа	`grant.access_token_lifetime`

Получите текущую конфигурацию приложения Access:
Необходимые разрешения API-токена

Хотя бы одно из следующих права доступа токена требуется:
- Access: Apps and Policies Write
- Access: Apps and Policies Read
Получение приложения Access
```
curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/apps/$APP_ID" \
	--request GET \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN"
```

Сделайте PUT запрос с настройками Managed OAuth. Чтобы не перезаписать существующую конфигурацию, тело запроса должно содержать все поля, возвращённые предыдущим GET запрос.

Необходимые разрешения API-токена

Хотя бы одно из следующих права доступа токена требуется:

Access: Apps and Policies Write

Обновление приложения Access

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"
				}
		}
	}'

Поток авторизации

Если управляемый OAuth включён, Access возвращает 401 ответ вместо 302 редирект на клиенты, отличные от браузера. 401 включает WWW-Authenticate заголовок, который указывает клиенту на метаданные обнаружения OAuth в Access.

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

Клиент получает метаданные сервера авторизации OAuth из /.well-known/ конечная точка:
```
https://<your-app-domain>/.well-known/oauth-authorization-server
```
Эта конечная точка соответствует RFC 8414 ↗ и RFC 9728 ↗ и возвращает URL-адреса конечных точек авторизации и токена для приложения.
Клиент инициирует authorization code flow. Он открывает браузер пользователя на странице авторизации Access, где пользователь обычно выполняет вход через свой IdP.
Access выдаёт клиенту OAuth-токен доступа. Клиент использует этот токен в последующих запросах к защищённому приложению.

Token format

Managed OAuth выдаёт непрозрачный токены доступа (например, oauth:CvNoo...), а не JSON Web Tokens (JWT). Это сделано намеренно: процесс OAuth позволяет клиентам выполнять запросы от имени пользователя, не раскрывая клиенту сведения о личности.

Когда клиент передаёт вашему приложению непрозрачный токен, Cloudflare на серверной стороне сопоставляет этот токен с личностью пользователя и передаёт вашему источнику подписанное утверждение. С точки зрения вашего источника такой запрос ничем не отличается от запроса, прошедшего аутентификацию через браузер.

Поскольку токен непрозрачен, клиент не может декодировать его или напрямую передать другим приложениям в виде JWT. Чтобы выполнять аутентифицированные запросы к нижестоящим приложениям Access, используйте Linked App Token шаблон: ваш источник считывает Cf-Access-Jwt-Assertion заголовок и передает его нижестоящим приложениям как Cf-Access-Token.

Многодоменные приложения

Если ваше приложение Access настроено с несколько доменов, токен OAuth, полученный через любой из доменов, действителен для всех доменов в рамках одного приложения. Пользователь проходит аутентификацию один раз и может использовать этот же токен для доступа ко всем доменам без дополнительных запросов.

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

Managed OAuth против токенов службы

И управляемый OAuth, и токены службы позволяют клиентам без браузера проходить аутентификацию в приложениях, защищённых Access, но они предназначены для разных сценариев использования:

	Managed OAuth	Service tokens
Модель аутентификации	На основе пользователя: конечный пользователь входит через своего поставщика идентификации	На основе устройства: общий секретный ключ проверяет подлинность самой службы
Подходит для	Интерактивные CLI-инструменты, ИИ-агенты, SDK, где запрос инициирует человек	Полностью автоматизированные системы, cron-задания, конвейеры CI/CD, взаимодействие между серверами
Личность пользователя	Access знает, какой пользователь отправил запрос	Идентификация пользователя отсутствует: запросы связываются с токеном службы
Применение политики	Может использовать политики на основе идентификации (например, требовать определённые группы или адреса электронной почты)	Требует Service Auth действие политики
Управление учётными данными	Общие секреты не нужно распространять: пользователи проходят аутентификацию с помощью собственных учётных данных	Требует распространения и ротации Client ID и Client Secret

Используйте Managed OAuth, если хотите, чтобы клиенты без браузера аутентифицировали пользователей так же, как это делает браузер: пользователь входит в систему один раз, а клиент получает OAuth-токен для выполнения запросов от его имени.

Используйте токены службы, если в процессе не участвует человек и нужна машинная идентичность для программного доступа к приложению.