> ## Documentation Index
> Fetch the complete documentation index at: https://veriqa.app/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Veriqa, BCP 247 и модель угроз

> Статус в Veriqa каждой из 17 мер защиты кросс-девайсного входа из RFC 10027 (BCP 247) — исходные данные для оценки рисков, которую RFC требует до внедрения, — и что сделать с непокрытыми мерами уже сейчас.

[RFC 10027](https://www.rfc-editor.org/rfc/rfc10027) — Best Current Practice 247 от IETF о
безопасности кросс-девайсных потоков, опубликован в августе 2026 года. Он описывает ту модель угроз,
в которой работает Veriqa: вход начинается в браузере на одном устройстве, а подтверждается на
телефоне в мессенджере. RFC требует оценить риски до внедрения кросс-девайсного входа и выбрать меры
под эту оценку (§2, п. 1 и 4, MUST). Таблица ниже — исходные данные для такой оценки: по каждой из
17 практических мер раздела 6.1 видно, есть ли она в Veriqa и где это проверить, а для непокрытых —
что можно сделать уже сейчас.

Сверено с текстом RFC и с исходным кодом Veriqa 5 ноября 2026 года.

## Итог

Из 17 мер §6.1 Veriqa покрывает **7**, частично — **2**, не покрывает — **6**; ещё **2** адресованы
не серверу авторизации.

В таблице ниже вы найдёте подробное описание каждой меры и связанных с ней рисков, в том числе —
как обеспечить меры, которых нет в ядре Veriqa.

Чтобы понять, много или мало покрывает Veriqa, мы решили сравнить, насколько полно эти меры
покрывают другие распространённые способы входа. Но RFC 10027 вышел в августе 2026 года, и оценок
других способов по нему почти нет, поэтому мы оценили их сами по той же таблице.
Код из SMS покрывает 2 меры, частично — 2; ещё 7 мер определяет сервер, который шлёт код, а не сам способ. Вход Google по коду на другом устройстве (RFC 8628) по
[документации Google](https://developers.google.com/identity/protocols/oauth2/limited-input-device) покрывает 3 меры, частично — 2; своей оценки по BCP 247 Google не
публиковал.

В независимом [разборе для Amazon Cognito](https://hidekazu-konishi.com/entry/browser_and_cross_device_oauth_on_amazon_cognito.html) настройки нашлись для 3 мер из 17, для 5 не
нашлись, остальные 9 разбор не рассматривает.

## Модель угроз

В терминах RFC Veriqa — сервер авторизации (Authorization Server). Браузер, где начат вход, —
Consumption Device, телефон с мессенджером — Authorization Device. QR-код или ссылка переходят с
одного устройства на другое по неаутентифицированному каналу, и проверяет его только человек: «The
only mitigation against this unauthenticated channel is the user's judgment» (§1.1).

На этом строится фишинг согласия — Cross-Device Consent Phishing (CDCP). Атакующий сам начинает вход
в приложение и под каким-нибудь предлогом передаёт жертве свой QR-код или показывает его на
поддельной странице. Жертва подтверждает вход в своём мессенджере, и сессия открывается у
атакующего. Аккаунт мессенджера атакующий не получает — он получает вход в приложение. Потоки Veriqa
относятся к кросс-девайсной авторизации (§3.1), поэтому второе семейство угроз RFC — фишинг передачи
сессии (CDSP, §3.2) — их не касается.

Потоки Veriqa соответствуют шаблонам §3.1 так (соответствие выведено из определений RFC, о Veriqa
сам RFC не упоминает):

| Поток Veriqa | Шаблон RFC |
| - | - |
| QR-код или ссылка в мессенджер, письмо в один тап, подтверждение, которое создаёт ваш сервер | User-Transferred Session Data (§3.1.1) — тот же класс, что RFC 8628 |
| Ссылка в письме, отправленном на адрес со страницы входа | Backchannel-Transferred Session (§3.1.2) — класс CIBA |
| Код из письма, введённый на странице входа | User-Transferred Authorization Data (§3.1.3) |

Контекст инициатора в вопросе, короткий срок жизни и одноразовые коды снижают риск, но от пересылки
входа не защищают. От неё защищает только [обязательный passkey](#passkey-вместе-с-veriqa).
[Фактор места](#близость-устройств-и-фактор-места) с выбором поверхности по сессии лишь не пускает
дальше браузеры вне офиса, и только если ваше приложение открывает доступ после проверки
присутствия. Так же действует [вход из доверенных сетей](https://veriqa.app/docs/ru/scenarios/trusted-network.md):
он лишь не пускает браузеры вне этих сетей.

## Меры §6.1 в Veriqa

Статусы: **покрыто** — механизм Veriqa делает то, что описывает мера; **частично** — покрыта часть
меры или только один из потоков; **не покрыто** — в Veriqa этого нет; **вне продукта** — мера
адресована не серверу авторизации. Таблица оценивает прежде всего вход; подтверждение, которое создаёт
ваш сервер, учтено там, где оно дополняет вход. Названия мер — как в RFC.

| § | Мера | Что есть в Veriqa | Статус | Где проверить |
| - | - | - | - | - |
| 6.1.1 | Establish Proximity | Ни одного из четырёх способов RFC — физическое подключение, радио, общая сеть, геолокация — нет. В hop-режиме Veriqa собирает контекст телефона, отсканировавшего QR-код, как сигнал риска, но с устройством входа его не сопоставляет. Фактор места работает уже сейчас как рецепт: после входа человек сканирует QR-код на поверхности в офисе — принтере, экране переговорной, IP-телефоне — и подтверждает в мессенджере, а ваш сервис выбирает поверхность по сети или рабочему месту сессии. Что сделать: [passkey](#passkey-вместе-с-veriqa), [фактор места](#близость-устройств-и-фактор-места); направление — [уровни привязки](#уровни-привязки) | не покрыто | [Hop-режим](https://veriqa.app/docs/ru/concepts/hop-mode.md#безопасность) |
| 6.1.2 | Short-Lived/Time-Bound QR or User Codes | Транзакция входа живёт 300 секунд по умолчанию, подтверждение, которое создаёт ваш сервер, — от 60 до 1800 секунд; у одноразовой hop-ссылки свой срок | покрыто | [`TransactionTtlSeconds`](https://veriqa.app/docs/ru/reference/configuration#veriqatransactionengine), [`ttl_seconds`](https://veriqa.app/docs/ru/reference/confirmation-api#3-создайте-подтверждение), `HopMode.TokenLifetime` |
| 6.1.3 | One-Time or Limited-Use Codes | Транзакция подтверждается один раз, завершённая не повторяется; hop-ссылка и handle связки одноразовые | покрыто | [Hop-режим](https://veriqa.app/docs/ru/concepts/hop-mode.md), [handle связки](https://veriqa.app/docs/ru/scenarios/channel-linking.md#два-бота-передача-пользователя-вашему-боту) |
| 6.1.4 | Unique Codes | Идентификатор транзакции — 256 случайных бит из криптографически стойкого генератора. Транзакция привязывается к аккаунту канала, в котором её открыли первым, — по QR-коду или по ссылке, — и любой другой аккаунт получает отказ; токены по ней выдаются один раз. Так выполняется отказ при повторном предъявлении (MAY), а роль списка использованных кодов играет состояние транзакции. Если hop-ссылку открывают повторно в другом браузере, Veriqa предупреждает об этом пользователя | покрыто | `TransactionId.NewId`, `TransactionService.BindChannelSubjectAsync` в исходном коде; `HopMode.WarnOnRepeatScan`, по умолчанию `true` — [Hop-режим](https://veriqa.app/docs/ru/concepts/hop-mode.md#главные-отличия) |
| 6.1.5 | Content Filtering | Письма и сообщения фильтруют почтовые сервисы и мессенджеры | вне продукта | — |
| 6.1.6 | Detect and Remediate | Журнал аудита транзакций, пометка необычного контекста входа, отзыв токенов и интроспекция для клиентов с разрешением. Цепочки «обнаружил атаку → отозвал токены, выданные по этому коду → известил серверы ресурсов» нет, пометка необычного контекста по умолчанию выключена, а истории входов для сравнения у неё пока нет; кнопки «это был не я» и CAEP нет. Направление — [распознавание аномалий](#распознавание-аномалий) | частично | [Аудит](https://veriqa.app/docs/ru/guides/hardening.md#логирование-и-аудит), [`AnomalyDetection:Enabled`](https://veriqa.app/docs/ru/reference/configuration#veriqainitiatorcontext), [`EnableRevocation`](https://veriqa.app/docs/ru/reference/configuration#server), [интроспекция](https://veriqa.app/docs/ru/reference/oidc-capabilities.md) |
| 6.1.7 | Trusted Devices | В ядре реестра доверенных устройств, с которых разрешено начинать вход, нет: вход начинает любой браузер. Подтверждение создаёт только конфиденциальный клиент вашего бэкенда. В сценарии фактора места устройство показа выбирает и регистрирует интегратор. Направление — [метка браузера](#метка-браузера) | не покрыто | [Получение токена](https://veriqa.app/docs/ru/reference/confirmation-api.md#2-получите-токен) |
| 6.1.8 | Trusted Networks | В ядре списка сетей, из которых разрешено начинать вход, нет; `KnownIPNetworks` задаёт только доверие к прокси. Сегодня вход ограничивает периметр развёртывания. Что сделать и направление — [доверенная сеть](#доверенная-сеть) | не покрыто | [Инфраструктура](https://veriqa.app/docs/ru/reference/configuration.md#инфраструктура) |
| 6.1.9 | Limited Scopes | Настройкой: `AllowedScopes` клиента. Все потоки Veriqa кросс-девайсные, поэтому scopes клиента и есть scopes этих потоков. Сужения по риску — по устройству или месту — нет; RFC его допускает, но не требует («may be further refined») | покрыто | [Клиенты](https://veriqa.app/docs/ru/reference/configuration.md#clients) |
| 6.1.10 | Short-Lived Tokens | Настройкой: access-токен живёт 3600 секунд, refresh-токен — 1 209 600 секунд (14 дней), ротация refresh-токена включена | покрыто | [Сервер](https://veriqa.app/docs/ru/reference/configuration.md#server), [ротация](https://veriqa.app/docs/ru/guides/hardening.md#ротация-refresh-токенов) |
| 6.1.11 | Rate Limits | Лимиты маршрутов (начало входа — 60 в минуту, создание подтверждения — 60 в минуту на клиента, старт входа по Email — 5 в минуту) и лимит на пользователя канала — 5 в минуту. Письма входа считаются и на получателя: 5 в час на адрес, на домен — если включено | покрыто | [`Veriqa:RateLimit`](https://veriqa.app/docs/ru/reference/configuration#veriqaratelimit), [лимиты](https://veriqa.app/docs/ru/guides/hardening.md#rate-limiting-и-anti-abuse), [письма на адрес](https://veriqa.app/docs/ru/guides/channels.md#повторная-отправка-письма) |
| 6.1.12 | Sender-Constrained Tokens | Токены не привязаны к ключу отправителя: DPoP и mTLS нет. Направления на этой странице нет | не покрыто | [Поддержка OIDC](https://veriqa.app/docs/ru/reference/oidc-capabilities.md#чего-нет) |
| 6.1.13 | User Education | Обучает своих пользователей сервис интегратора; в RFC это мера уровня MAY | вне продукта | — |
| 6.1.14 | User Experience | Вопрос в мессенджере называет приложение, время запроса, браузер, ОС и регион инициатора и заканчивается советом `If it was not you, decline the request.` («Если это не вы — отклоните запрос»). Под ним кнопки «Подтвердить ✅» и «Отклонить ❌», отказ отмечен красным крестиком. На странице Veriqa, которая спрашивает «Да» или «Нет», и на странице входа через аккаунт провайдера ответ по умолчанию — «Нет»: эта кнопка залита основным цветом и в фокусе при открытии, «Да» — контурная. На сенсорном экране страница провайдера принимает «Да» только сдвигом шторки. В подтверждении, которое создаёт ваш сервер, текст вопроса пишете вы, и совет об отказе в нём есть, если вы его добавили | покрыто | [Контекст инициатора](https://veriqa.app/docs/ru/concepts/initiator-context.md), [`Veriqa:LoginConfirmation`](https://veriqa.app/docs/ru/reference/configuration#veriqaloginconfirmation), [`ConfirmSlider`](https://veriqa.app/docs/ru/guides/channels#вход-через-аккаунт-провайдера), [шаблоны подтверждения](https://veriqa.app/docs/ru/reference/confirmation-api.md#шаблоны) |
| 6.1.15 | Authenticate then Initiate | Для подтверждения, которое создаёт ваш сервер: его начинает бэкенд после входа пользователя, а `expected_identities` оставляет право подтвердить только владельцу аккаунта. Повторный вход перед рискованной операцией тоже начинает уже вошедший пользователь: рецепт step-up сверяет `sub` и `auth_time` в новом `id_token`. К самому входу мера неприменима: его начинает тот, кто ещё не вошёл. Мера предполагает перед этим вход, устойчивый к фишингу, — такой вход даёт [обязательный passkey](#passkey-вместе-с-veriqa) | частично | [Что проверяете](https://veriqa.app/docs/ru/scenarios/step-up.md#что-проверяете) |
| 6.1.16 | Request Initiation Verification | Отдельной ступени с одноразовым кодом нет. Вход по коду из письма — сам поток (§3.1.3), а не добавочная проверка. Направление — [уровни привязки](#уровни-привязки) | не покрыто | [Ссылка, код или оба](https://veriqa.app/docs/ru/guides/channels.md#ссылка-код-или-оба) |
| 6.1.17 | Request Binding with Out-of-Band Data | Нет. Направления на этой странице нет | не покрыто | — |

## Ограничения и направления

У направлений нет сроков, состояние указано у каждого, а у запланированных — ссылка на
[план релизов](https://veriqa.app/docs/ru/releases/next.md).

### Близость устройств и фактор места

**Что не покрыто.** Ни одного способа близости из §6.1.1 в Veriqa нет: мессенджер не даёт серверу ни
радио, ни общей сети с браузером входа.

**Что сделать уже сейчас.** Соберите фактор места по сценарию
[«Место и личность»](https://veriqa.app/docs/ru/scenarios/place-and-identity.md): после входа человек сканирует QR-код на
принтере, экране в переговорной или IP-телефоне и подтверждает в мессенджере. Это компенсирующая мера
под оценку рисков, а не способ из §6.1.1: она проверяет близость телефона к поверхности места, а не к
устройству входа.

Атака CDCP держится на расстоянии и масштабе: RFC описывает её как рассылку кодов «to large numbers of
users that are geographically distributed» (§6.1.1). QR-код на листе из офисного принтера или на
панели в переговорной удалённо не доставить и тысяче адресатов не разослать. Там, где политика
периметра запрещает радио, близость FIDO по Bluetooth не работает вовсе (обоим устройствам нужен BLE,
§6.2.3.3), а бумажному и экранному QR-коду радио не нужно.

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

**Направление.** Ядро само печатало бы QR-код места через адаптер устройства, а браузер его не
показывал бы. Тогда QR-код места ни разу не появлялся бы на экране, и его не увидели бы ни удалённый
рабочий стол, ни демонстрация экрана. Состояние: обсуждается.

### Passkey вместе с Veriqa

**Что не покрыто.** Подтверждение в мессенджере ничем не связано с браузером, где открывается сессия,
поэтому вход через Veriqa не устойчив к фишингу.

**Что сделать уже сейчас.** Сценарий [«Passkey вместе с Veriqa»](https://veriqa.app/docs/ru/scenarios/passkey-with-veriqa.md):
пользователь заводит passkey по кнопке, которая приходит в мессенджер после входа, а приложение
требует ключ до того, как откроет сессию. Ключ не подписывает запрос для чужого адреса. Вход ключом с
другого устройства требует Bluetooth рядом с браузером входа (§6.2.3.3). Это способ близости из
§6.1.1 и вход, устойчивый к фишингу, который описывает §6.1.15. RFC советует FIDO2/WebAuthn везде, где
устройства это умеют (§6.2.3.5, SHOULD).

Защищает только обязательный режим и только тех пользователей, у кого он включён: пока вход без ключа
открыт, атакующий им и воспользуется. Ключ нельзя давать завести из сессии, открытой через Veriqa:
сессия могла достаться атакующему. Следующие ключи добавляйте только после подписи существующим.
Слабым местом остаётся заведение первого ключа: ссылка из кнопки действует на предъявителя.

**Направление.** Passkey как ступень [уровней привязки](#уровни-привязки).

### Уровни привязки

**Что не покрыто.** Подтверждение не связано криптографически с браузером, начавшим вход (§6.1.1,
§6.1.16).

**Что сделать уже сейчас.** [Passkey вместе с Veriqa](#passkey-вместе-с-veriqa).

**Направление.** Спецификация уровней привязки описывает шкалу доверия между браузером,
начавшим вход, и тем, кто подтверждает. Её цель — уровень, на котором подтверждение принимается
только от того же устройства или от устройства, заранее связанного с ним криптографически. Кандидаты
механизма — passkey как дополнительная ступень, ключ канала и ссылка из письма, которую принимает
только браузер, начавший вход. Последний вариант убрал бы кросс-девайсность у входа по письму вовсе
(§2, п. 2). Без нормативной силы спецификация упоминает и сверку числа — по смыслу §6.1.16, с тем же
ограничением, что называет RFC: атакующий, который ведёт жертву интерактивно, попросит у неё и число.
Конкретный механизм спецификация не обещает. Состояние: запланировано на релиз после следующего —
см. [план релизов](https://veriqa.app/docs/ru/releases/next.md).

### Распознавание аномалий

**Что не покрыто.** Цепочки «обнаружил атаку → отозвал токены, выданные по этому коду → известил
серверы ресурсов» нет, кнопки «это был не я» и CAEP тоже нет (§6.1.6). Переключатель
`AnomalyDetection:Enabled` есть, но истории подтверждённых входов, с которой можно сравнивать, ядро
пока не хранит, поэтому пометка не работает и при включённом переключателе.

**Что сделать уже сейчас.** Следите за [журналом аудита транзакций](https://veriqa.app/docs/ru/guides/hardening.md#логирование-и-аудит)
и отзывайте токены входа, который человек не начинал
([`EnableRevocation`](https://veriqa.app/docs/ru/reference/configuration#server)).

**Направление.** Veriqa запоминала бы производные неперсональные признаки подтверждённых входов —
страну и тип устройства — и помечала бы вход, который с ними не совпадает. IP, User-Agent и город не
хранились бы, а включалась бы функция по желанию. Это частично покрыло бы обнаружение из §6.1.6, а
отзыв токенов и оповещение серверов ресурсов остались бы за вашим сервисом. Состояние: запланировано
на следующий релиз — см. [план релизов](https://veriqa.app/docs/ru/releases/next.md).

### Метка браузера

**Что не покрыто.** Вход начинает любой браузер, и Veriqa не отличает браузер, которым человек уже
входил (§6.1.7).

**Что сделать уже сейчас.** Ваше приложение знает свои устройства: незнакомому браузеру оно может не
открывать сессию без дополнительной проверки, например passkey.

**Направление.** Метка браузера — cookie на адресе Veriqa под Data Protection (шифрование и подпись),
`HttpOnly`, `Secure`. Незнакомый браузер не получал бы код авторизации, а сессия открывалась бы в
знакомом: вход в нём начинался бы заново по инициативе третьей стороны (OpenID Connect Core, §4).
Веб-пуш свёл бы это к одному нажатию. Браузер атакующего метки этого человека не несёт, а
страница-подделка cookie адреса Veriqa не видит.

Мера покрыла бы §6.1.7 частично. Доверие получает браузер, которым человек уже входил, а не
устройство, зарегистрированное сервером. Cookie — не аттестация, и RFC указывает на это в ограничениях
меры. Предел — новый компьютер и первый вход. Метка надёжна ровно настолько, насколько защищено кольцо
ключей Data Protection: кто читает кольцо, тот подделает и метку. Шифруйте кольцо сертификатом —
[`Veriqa:DataProtection:CertificateBase64` или `:CertificatePath`](https://veriqa.app/docs/ru/reference/configuration#инфраструктура).
Состояние: обсуждается.

### Доверенная сеть

**Что не покрыто.** Списка сетей, из которых разрешено начинать вход, в Veriqa нет (§6.1.8).

**Что сделать уже сейчас.** Сценарий [«Вход из доверенных сетей»](https://veriqa.app/docs/ru/scenarios/trusted-network.md):
ограничьте по сети на обратном прокси маршрут `/connect/authorize`, которым начинается вход, а
маршруты, на которые приходят телефон и вебхуки каналов, оставьте доступными.

**Направление.** Запись клиента хранила бы список сетей, из которых разрешено начинать вход. RFC
советует сочетать такую меру с другими (§6.1.8, SHOULD). Состояние: обсуждается.

### Служебный адрес

**Что не покрыто.** Для незнакомого браузера при первом входе проверки нет.

**Направление.** Мессенджер просил бы набрать служебный адрес Veriqa вручную, и Veriqa сверяла бы
браузер с тем, что начал вход. Проверка работала бы и при первом входе, но держалась бы на человеке:
подделка может увести его на свою служебную страницу. Ни одной меры §6.1 буквально не покрывает — это
усиление. Состояние: обсуждается.

### Цепочка из нескольких каналов

Спецификация цепочки каналов описывает вход, который подтверждается в нескольких каналах подряд. Она
защищает от угона одного канального аккаунта: одной украденной сессии мессенджера атакующему не
хватит. От пересылки входа цепочка не защищает — каждое её звено пересылается так же, — и строк
таблицы не меняет. Собрать её можно уже сейчас по сценарию
[«Усиленный вход цепочкой каналов»](https://veriqa.app/docs/ru/scenarios/auth-chain.md). Состояние встроенной поддержки:
заморожено.

## Выбор протокола (§6.2)

§6.2 сравнивает три протокола: RFC 8628, CIBA и FIDO2/WebAuthn. Вход через Veriqa ни один из них не
использует: приложение получает токены по коду авторизации с PKCE (OpenID Connect), а кросс-девайсный
шаг идёт между страницей Veriqa и мессенджером. RFC 8628 и CIBA описывают, как устройство получит
токен; Veriqa отвечает на другой вопрос — чем человек докажет, что это он.

FIDO2/WebAuthn RFC советует использовать везде, где устройства это умеют (§6.2.3.5, SHOULD), и
допускает в связке с кодом авторизации и PKCE (MAY) — так устроен сценарий
[«Passkey вместе с Veriqa»](https://veriqa.app/docs/ru/scenarios/passkey-with-veriqa.md). Где Bluetooth запрещён или его нет,
вход ключом с телефона на компьютер не работает (§6.2.3.3), а вход через мессенджер работает.

## Дальше

> [card] [Подготовка к продакшну](https://veriqa.app/docs/ru/guides/hardening.md)
>
> Лимиты, аудит, сертификаты и ротация токенов перед запуском.

> [card] [Контекст инициатора](https://veriqa.app/docs/ru/concepts/initiator-context.md)
>
> Что видит человек в вопросе о входе.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.