Безопасный OAuth для ИИ-агентов: доступ к внутренним приложениям в один клик

В Cloudflare у нас есть тысячи внутренних приложений. Некоторые мы построили сами, другие — это самодельные экземпляры программного обеспечения, созданного другими. Их спектр варьируется от критически важных для бизнеса приложений, которыми пользуется почти каждый сотрудник, до побочных проектов и прототипов.

Все эти приложения защищены Cloudflare Access. Но когда мы начали использовать и создавать агентов — особенно для задач, выходящих за рамки написания кода — мы столкнулись с препятствием. Люди могли получать доступ к приложениям за Access, а их агенты — нет.

Access располагается перед внутренними приложениями. Вы определяете политику, и тогда Access будет направлять неаутентифицированных пользователей на страницу входа для выбора способа аутентификации.

^{Пример страницы входа Cloudflare Access}

Этот поток отлично работал для людей. Но всё, что видели агенты, — это перенаправление на страницу входа, на которую они не могли реагировать.

Предоставление агентам доступа к данным внутренних приложений настолько важно, что мы немедленно внедрили временное решение для собственного внутреннего использования. Мы модифицировали инструмент получения веб-данных (web fetch tool) от OpenCode так, что для определённых доменов он запускал CLI cloudflared для открытия потока авторизации и получения JWT (JSON Web Token). Добавляя этот токен к запросам, мы обеспечили безопасный и мгновенный доступ к нашей внутренней экосистеме.

Хотя это решение было временным ответом на нашу собственную дилемму, сегодня мы отказываемся от этого обходного пути и исправляем проблему для всех. Теперь в открытой бета-версии каждое приложение Access поддерживает управляемый OAuth. Один клик для его включения в приложении Access, и агенты, поддерживающие OAuth 2.0, могут легко обнаружить, как аутентифицироваться (RFC 9728), отправить пользователя через поток авторизации и получить обратно токен авторизации (тот же JWT из нашего первоначального решения).

Теперь поток работает гладко как для людей, так и для агентов. Cloudflare Access имеет щедрый бесплатный тарифный план. И, опираясь на нашу недавно представленную бета-версию Organizations, вы скоро сможете также объединять провайдеров идентификации между аккаунтами Cloudflare.

Для данного внутреннего приложения, защищённого Cloudflare Access, вы включаете управляемый OAuth одним кликом:

Как только управляемый OAuth включён, Cloudflare Access выступает в роли сервера авторизации. Он возвращает заголовок www-authenticate, сообщая неавторизованным агентам, где искать информацию о том, как получить токен авторизации. Они находят её по адресу https://<ваш-домен-приложения>/.well-known/oauth-authorization-server. Имея это указание, агенты могут просто следовать стандартам OAuth:

1. Агент динамически регистрирует себя как клиента (процесс, известный как Динамическая регистрация клиента — RFC 7591),

2. Агент отправляет человека через поток авторизации PKCE (Proof Key for Code Exchange, подтверждение ключа для обмена кодом) (RFC 7636)

3. Человек авторизует доступ, что предоставляет агенту токен, который он может использовать для выполнения аутентифицированных запросов от имени пользователя

Вот как выглядит поток авторизации:

Если этот поток авторизации выглядит знакомо, то это потому, что его использует Model Context Protocol (MCP). Изначально мы встроили поддержку этого в наш продукт MCP server portals, который проксирует и контролирует доступ ко многим MCP-серверам, чтобы позволить порталу выступать в роли OAuth-сервера. Теперь мы применяем это ко всем приложениям Access, чтобы агенты могли получать доступ не только к MCP-серверам, требующим авторизации, но и к веб-страницам, веб-приложениям и REST API.

Обновление длинного хвоста внутреннего программного обеспечения для работы с агентами — пугающая задача. В принципе, чтобы быть готовыми к агентам, каждое внутреннее и внешнее приложение в идеале должно иметь обнаруживаемые API, CLI, хорошо продуманный MCP-сервер и внедрить множество появляющихся стандартов для агентов.

Внедрение ИИ не может ждать, пока всё будет модернизировано. У большинства организаций есть значительный бэклог приложений, созданных за многие годы. И многие внутренние «приложения» отлично работают, когда агенты обращаются с ними как с простыми веб-сайтами. Для чего-то вроде внутренней вики, всё, что действительно нужно, — это включить Markdown для агентов, активировать управляемый OAuth, и у агентов появится всё необходимое для чтения защищённого контента.

Чтобы базовые функции работали в самом широком наборе внутренних приложений, мы используем управляемый OAuth. Размещая Access перед вашими устаревшими внутренними приложениями, вы мгновенно делаете их готовыми к агентам. Никаких изменений кода, никакой модернизации. Только немедленная совместимость.

Агентам необходимо действовать от имени пользователей внутри организаций. Один из самых больших антипаттернов, который мы наблюдали, — это создание сервисных учётных записей для своих агентов и MCP-серверов, аутентифицируемых с помощью статических учётных данных. У них есть своё место в простых случаях использования и быстрых прототипах, и Cloudflare Access поддерживает сервисные токены для этой цели.

Но подход с сервисными учётными записями быстро показывает свои ограничения, когда требуются детализированный контроль доступа и журналы аудита. Мы считаем, что каждое действие, выполняемое агентом, должно быть легко соотносимо с человеком, который его инициировал, и что агент должен иметь возможность выполнять только те действия, которые его оператор-человек также имеет право выполнять. Сервисные учётные записи и статические учётные данные становятся точками, в которых теряется атрибуция. Агенты, которые проводят все свои действия через сервисную учётную запись, подвержены проблемам запутанного посредника (confused deputy problems) и приводят к журналам аудита, которые, кажется, исходят от самого агента.

Для безопасности и подотчётности агенты должны использовать примитивы безопасности, способные выражать эти отношения «пользователь-агент». OAuth — это отраслевой стандартный протокол для запроса и делегирования доступа третьим сторонам. Он даёт агентам способ взаимодействия с вашими API от имени пользователя, с токеном, привязанным к идентификатору пользователя, чтобы правила контроля доступа применялись корректно, а журналы аудита правильно приписывали действия конечному пользователю.

RFC 9728 — это стандарт OAuth, который делает возможным для агентов обнаруживать, где и как аутентифицироваться. Он стандартизирует местонахождение и структуру этой информации. Этот RFC стал официальным в апреле 2025 года и был быстро принят Model Context Protocol (MCP), который теперь требует, чтобы и MCP-серверы, и клиенты поддерживали его.

Но за пределами MCP агенты должны внедрять RFC 9728 для ещё более важного случая использования: выполнения запросов к веб-страницам, защищённым OAuth, и запросов к простым старым REST API.

У большинства агентов есть инструмент для выполнения базовых HTTP-запросов к веб-страницам. Обычно он называется инструментом «web fetch». Он похож на использование API fetch() в JavaScript, часто с дополнительной постобработкой ответа. Именно он позволяет вставить URL-адрес в ваш агент и поручить агенту найти контент.

Сегодня инструменты web fetch большинства агентов ничего не делают с заголовком www-authenticate, который возвращает URL. Базовая модель может решить проанализировать заголовки ответа и разобраться в этом самостоятельно, но сам инструмент не следует по www-authenticate, не ищет /.well-known/oauth-authorization-server и не выступает в роли клиента в потоке OAuth. Но он может, и мы твёрдо верим, что он должен! Агенты уже делают это, чтобы выступать в роли удалённых MCP-клиентов.

В качестве демонстрации мы создали черновик pull request, который адаптирует инструмент web fetch в Opencode, чтобы показать это в действии. Перед выполнением запроса адаптированный инструмент сначала проверяет, есть ли у него уже учётные данные; если есть, он использует их для выполнения начального запроса. Если инструмент получает в ответ 401 или 403 с заголовком www-authenticate, он запрашивает у пользователя согласие на прохождение OAuth-потока сервера.

Вот как работает этот OAuth-поток. Если вы дадите агенту URL, защищённый OAuth и соответствующий RFC 9728, агент запросит у человека согласие на запуск потока авторизации:

…отправляя человека на страницу входа:

…а затем в диалог согласия, который запрашивает у человека разрешение на доступ для агента:

Как только человек предоставляет доступ агенту, агент использует полученный токен для выполнения аутентифицированного запроса:

Любой агент, от Codex до Claude Code, Goose и далее, может это реализовать, и здесь нет ничего специфичного для Cloudflare. Всё построено на стандартах OAuth.

Мы считаем этот поток мощным и полагаем, что поддержка RFC 9728 может помочь агентам не только в выполнении простых веб-запросов. Если REST API поддерживает RFC 9728 (и агент тоже), то у агента есть всё необходимое, чтобы начать выполнять аутентифицированные запросы к этому API. Если REST API поддерживает RFC 9727, то клиент может самостоятельно обнаружить каталог конечных точек REST API и делать ещё больше без дополнительной документации, навыков агентов, MCP-серверов или CLI.

Каждый из этих элементов играет важную роль в работе с агентами — сам Cloudflare предоставляет MCP-сервер для Cloudflare API (построенный с использованием Code Mode), CLI Wrangler, Навыки для агентов (Agent Skills) и Плагин. Но поддержка RFC 9728 помогает гарантировать, что даже когда ни один из этих инструментов не предустановлен, у агентов есть четкий путь вперед. Если у агента есть песочница для выполнения непроверенного кода, он может просто написать и выполнить код, который вызывает API, доступ к которому ему предоставил человек. Мы работаем над поддержкой этого для собственных API Cloudflare, чтобы помочь вашим агентам понять, как использовать Cloudflare.

В Cloudflare наши собственные внутренние приложения развернуты в десятках различных аккаунтов Cloudflare, которые являются частью Организации — недавно представленного способа для администраторов управлять пользователями, конфигурациями и просматривать аналитику по множеству аккаунтов Cloudflare. У нас была та же проблема, что и у многих наших клиентов: каждый аккаунт Cloudflare должен отдельно настраивать IdP, чтобы Cloudflare Access использовал нашего поставщика удостоверений. Крайне важно, чтобы это было единообразно в рамках организации — вы не хотите, чтобы один аккаунт Cloudflare случайно разрешал вход только по одноразовому PIN-коду, вместо требования аутентификации через единый вход (SSO).

Чтобы решить эту задачу, мы сейчас работаем над тем, чтобы сделать возможным совместное использование поставщика удостоверений между аккаунтами Cloudflare, предоставив организациям возможность назначить один основной IdP для использования во всех аккаунтах своей организации.

При создании новых аккаунтов Cloudflare внутри организации администраторы смогут настроить подключение к основному IdP одним щелчком, чтобы приложения Access во всех аккаунтах были защищены одним поставщиком удостоверений. Это устраняет необходимость вручную настраивать IdP для каждого аккаунта — процесс, который не масштабируется для организаций со множеством команд и отдельных лиц, каждый из которых управляет своими собственными аккаунтами.

В компаниях люди всех ролей и бизнес-функций теперь используют агентов для создания внутренних приложений и ожидают, что их агенты смогут получать контекст из внутренних приложений. Мы реагируем на этот скачкообразный рост внутренней разработки программного обеспечения, улучшая совместную работу Платформы Workers и Cloudflare One — чтобы создавать и защищать внутренние приложения на Cloudflare было проще.

Ожидайте новых анонсов в ближайшее время, включая:

• Более тесную интеграцию между Cloudflare Access и Cloudflare Workers без необходимости проверки JWT или запоминания, на каком из множества маршрутов открыт конкретный Worker.

• wrangler dev --tunnel — простой способ открыть ваш локальный сервер разработки для других, когда вы создаёте что-то новое и хотите поделиться этим до развертывания.

• Интерфейс командной строки (CLI) для Cloudflare Access и всего Cloudflare API.

• Другие анонсы в рамках Недели агентов (Agents Week) 2026.