Кратко

  • Атакующий запускает штатный поток на своём устройстве и передаёт жертве подлинный код или адрес проверки. Жертва входит на настоящем сервисе, а действительный токен возвращается клиенту атакующего.
  • До согласия необходимо связать инициатора, клиент, устройство потребления, ресурс, scope, действие и последствие; после выдачи — проследить использование токена, отзыв и закрытие каждой зависимой сессии.

Мнимый сотрудник поддержки предлагает «подключить экран переговорной» и диктует код. Администратор открывает официальный сайт на служебном телефоне, применяет passkey и подтверждает действие. Экран не подключается: код запросил клиент, открытый у собеседника.

Подделки страницы не было. Пароль не утёк. Сервер точно выполнил протокол. Неверным оказался смысл связи между двумя устройствами.

RFC 10027, выпущенный в августе 2026 года как BCP 247, разделяет межустройственную авторизацию и перенос сессии и описывает атаки между протоколами и внутри одного протокола. Их поверхность — неаутентифицированный канал контекста между Consumption Device, где возникает запрос, и Authorization Device, где человек подтверждает его.

Код указывает на запрос, но не удостоверяет инициатора

По RFC 8628 клиент получает device code и user code, показывает путь проверки и опрашивает сервер, пока пользователь завершает авторизацию на другом устройстве. Это подходит телевизорам и терминалам с ограниченным вводом, однако позволяет перенести ссылку на запрос вместе с ложным объяснением.

Короткий срок, одноразовость и уникальность сужают окно перебора и повторения. Интерактивный атакующий способен сначала убедить человека, затем создать свежий код и немедленно использовать первое одобрение. Отсутствие replay не доказывает, что пользователь сам начал поток.

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

Сильная проверка личности не описывает транзакцию

WebAuthn Level 3 даёт привязанную к origin и устойчивую к фишингу аутентификацию. Она доказывает, кто ответил настоящему relying party. Она не доказывает автоматически удалённое устройство, заявителя, ресурс, объём прав или необратимый результат, который представлял пользователь.

RFC 10027 рекомендует Device Grant лишь тогда, когда ограничения устройства исключают более сильные варианты, и советует избегать его для чувствительных, дорогостоящих и критичных ресурсов. Предварительная регистрация Consumption Device и принцип «сначала аутентифицируйся, затем инициируй» могут отсечь произвольный клиент.

Близость повышает цену атаки, но не является идентичностью. Мобильная сеть и Wi-Fi искажают видимую дистанцию, VPN, ретрансляция и подмена координат скрывают удалённость, а точное наблюдение расходует приватность. Второй канал полезен лишь тогда, когда отображённые факты действительно связаны с тем же request ID и сами не стали ещё одним пересылаемым секретом.

Защищённый токен может быть выдан не тому

DPoP связывает токен с клиентским ключом и ограничивает перенос украденной копии. Если атакующий контролирует авторизованное устройство и ключ, DPoP гарантирует, что ошибочно предоставленной властью воспользуется именно оно. RFC 9700 укрепляет OAuth 2.0, но не восстанавливает отсутствующее намерение.

OpenID CIBA убирает перенос видимого кода и уменьшает эту атаку. Однако заявитель, знающий идентификатор пользователя, способен вызвать prompt; остаются массовые запросы, усталость от подтверждений и легенда ложной поддержки.

При реагировании интроспекция, отзыв и события CAEP дают разные сигналы. Успех endpoint отзыва или отправка события не доказывают очистку кэша ресурсных серверов, завершение производных сессий и остановку всей семьи refresh token.

Журнал контекста вместо единого зелёного статуса

Нужно сохранять request ID, время и инициатора, client ID и версию, идентичность, регистрацию и доверие Consumption Device, Authorization Device и метод, хэш и срок кода, канал переноса, сигналы близости, а также точное отображение заявителя, устройства, ресурса, scope, действия, адресата и необратимого последствия.

После согласия семейство токенов и confirmation key связываются с использованием на каждом ресурсном сервере. Отказ, аномалия, интроспекция, отзыв, доставка и подтверждение CAEP, фактическое завершение сессии остаются отдельными состояниями.

Принцип Heng Lu о первичности работающего кода помещает операционную истину в клиент и ресурс, которые реально осуществляют доступ. Его минимальная начальная спецификация и локальные последующие решения поддерживают узкий общий контракт доказательств при локальном выборе доверия и близости. Различие формального и практического контроля показывает итог: сервер выдаёт формальное право, а ключ и живая сессия дают практическую власть.

Телефон установил, кто нажал кнопку. Организации ещё предстоит установить, чьему запросу досталась власть.