Кратко

  • RFC 10017 располагает три архитектуры по убыванию защищённости: полный BFF, сервер-посредник токенов и OAuth-клиент непосредственно в браузере.
  • Полный BFF не отдаёт JavaScript access token, refresh token и секретные полномочия клиента, однако вредоносный код в разрешённом origin по-прежнему может послать команду через действующую cookie-сессию.
  • Руководству необходимо раздельно управлять origin и поставкой кода, cookies и CSRF, хостами/путями/методами BFF, авторизацией ресурса, подтверждением необратимых действий, отзывом сессий и доказательством конечного результата.

Оператор открывает облачную консоль и меняет правило доступа. В браузере нет OAuth-токена: фронтенд пользуется HttpOnly cookie, а BFF хранит токены на сервере и вызывает API. Архитектурная проверка справедливо отмечает, что JavaScript не способен скопировать bearer credential.

Но внедрённый скрипт отправляет ещё одну команду — разрешить доступ более широкой группе. Браузер добавляет cookie. BFF принимает сессию, извлекает токен и пересылает запрос. Resource Server видит верный issuer, audience и scope и применяет правило. Секрет не покидал сервер; полномочие было использовано в неверной команде.

RFC 10017, опубликованный IETF в августе 2026 года как Best Current Practice, ценен именно этой точностью. BFF существенно уменьшает возможности злоумышленника. Он не делает любой код в зарегистрированном origin надёжным представителем пользователя.

После захвата контекста есть четыре пути

Модель RFC начинается с вредоносного JavaScript или WebAssembly, уже исполняющегося в контексте приложения. Такой код получает браузерные права легитимного кода: доступ к разрешённым данным и storage, взаимодействие с same-origin контекстами, изменение потока исполнения и отправку запросов из принятого origin.

Первый сценарий единожды похищает доступные токены. Второй остаётся в приложении и перехватывает каждое обновление. Третий не трогает хранилище, а запускает новый Authorization Code Flow, используя существующую пользовательскую сессию на Authorization Server. Четвёртый ничего не выносит: он заставляет сам браузер отправить запрос вместе с cookie, токеном или подписью, которые нормальный механизм добавляет автоматически.

Так становятся видны границы защит. Короткий access token сокращает жизнь одной копии, но постоянный код ждёт следующую. Refresh Token Rotation иногда обнаруживает reuse, однако атакующий может всегда брать последнюю версию и мешать её легитимному использованию. Изолированный Worker защищает существующее значение, не обязательно путь к выпуску нового.

PKCE обязателен и блокирует обмен перехваченного Authorization Code другой инстанцией. Он не различает намерение двух программ внутри одного зарегистрированного redirect origin. DPoP или non-exportable key мешают применить скопированный токен вне клиентской среды, но вредоносный same-origin код может начать новый Flow со своим ключом или использовать живой интерфейс подписи.

BFF закрывает три двери и становится четвёртой

В полном BFF серверный компонент является confidential OAuth client. Он выполняет Authorization Code с PKCE, хранит access и refresh tokens, связывает их с cookie-сессией и проксирует все вызовы Resource Servers. Фронтенд OAuth-токен не получает.

Три преимущества реальны. В браузере нет значения для разовой или постоянной кражи. Даже получив code, вредоносный скрипт не может обменять его как зарегистрированный confidential client без секретных полномочий BFF. HttpOnly также не позволяет прочитать идентификатор сессии и перенести его в другую среду.

Остаётся команда внутри контекста. Приложение должно иметь возможность вызывать BFF. Вредоносный код в том же origin вызывает тот же endpoint; браузер прикладывает cookie, BFF переводит сессию в token-bearing request. Злоумышленнику не нужно ломать vault — он использует предусмотренный канал управления.

Поэтому BFF не должен быть универсальным proxy. RFC 10017 требует строгого контроля исходящих запросов: заранее разрешённые hosts и paths, ограниченные HTTP methods. Параметр браузера не должен свободно выбирать URL, куда BFF понесёт токен. Иначе хорошая серверная custody превращается в открытый relay пользовательских полномочий.

У cookie отдельные требования. Secure и HttpOnly обязательны; SameSite=Strict, path /, отсутствие Domain и подходящий host-bound prefix рекомендуются. Но state-changing routes всё равно требуют CSRF-защиты: браузер способен приложить cookie, не раскрывая его JavaScript.

BFF концентрирует client credentials, token vault, session translation и routing. Это хорошее место для anomaly detection и rate limiting, а также критическая зависимость по ёмкости, межрегиональному состоянию, отзыву и восстановлению.

Посредник сохраняет refresh token и возвращает access token

Token-mediating backend остаётся confidential client и держит refresh token на сервере, но выдаёт access token браузеру для прямого вызова Resource Servers. Он сокращает proxy-нагрузку и возвращает в frontend именно краткосрочное полномочие.

Вредоносный код не похищает refresh token и не завершает новый Flow как confidential client. Зато он может скопировать access token. Даже если storage изолирован, код может запросить свежий токен у посредника через текущую сессию. Для необратимого эффекта нескольких минут достаточно.

DPoP-ответственность тоже разделяется: backend получает token, browser использует. RFC 10017 не определяет эту схему. Надпись PoP между двумя блоками не доказывает, кто хранит ключ и формирует Proof. Поэтому документ предлагает сначала оценить полный BFF и выбирать посредника лишь при конкретном системном ограничении.

Браузерный клиент остаётся публичным

Если JavaScript выполняет все OAuth-функции, встроенный secret не является конфиденциальным и не доказывает личность клиента. Обязательны Authorization Code с PKCE, точные Redirect URIs и CSRF-защита. Если браузеру выдаются refresh tokens, Authorization Server должен ротировать их при использовании либо sender-constrain, а также ограничить абсолютный или неактивный срок.

Эти правила не устраняют четыре сценария после захвата origin. Origin — сочетание scheme, host и port — становится практической границей полномочий. RFC 10017 рекомендует одно приложение на origin. Организационно разные продукты, размещённые вместе, делят браузерные возможности независимо от структуры команд.

CORS определяет, будет ли cross-origin response раскрыт браузерному коду. Он не является серверной авторизацией и не различает легитимный и вредоносный код внутри разрешённого origin. Для postMessage требуется точная проверка origin отправителя и получателя.

Service Worker не получает власть над origin

Service Worker способен изолировать токены и прикладывать их к запросам, словно локальный BFF. RFC 10017 не рекомендует поручать ему OAuth Flow: вредоносный код может unregister Worker и открыть новый Browsing Context без его перехвата, где запустит новый Flow.

Изоляция существующего токена реальна, но не превращает Worker в неотменяемую власть. Non-exportable ключ Web Crypto тоже гарантирует свойство API, а не обязательный TPM или шифрованное хранение на диске. Неверный код может всё ещё попросить правильную среду применить ключ.

Свидетельство должно дойти до commit

Полезная цепочка связывает origin и версию frontend, зависимости и CSP, privacy-safe session hash, CSRF result, BFF route, upstream host/path/method, audience и scopes токена, версию Resource Policy, состояние объекта, idempotency key и commit result. Сырые tokens, cookies и client secrets не записываются.

Негативные тесты разделяют способности: прочитать token, следить за rotation, начать новый Flow, получить token у посредника, использовать BFF без token theft, изменить destination и повторить необратимое действие после потерянного response. Один статус «OAuth valid» стирает нужную причинность.

Running-Code Primacy требует смотреть на исполнение. BFF — название; cookies, route maps, vault, resource decisions и failure behavior — реальность. Minimum Initial Specification сохраняет общие правила OAuth точными, а финальное решение оставляет сервису, который несёт последствия. Защищённый токен не является доверенностью на любую команду.