> ## 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 отличается

> Сравнение с passkeys, встроенными виджетами входа мессенджеров, SMS-кодами и device flow: где Veriqa сильнее, а где проходит граница.

Veriqa дополняет существующие решения, а не заменяет их. Ниже — где она сильнее и где проходит
граница.

Общее для всего сравнения: основной сценарий Veriqa — **кросс-девайсный**. Приложение открыто на
десктопе, ТВ или киоске, а подтверждение происходит на телефоне, в мессенджере, который у
пользователя и так открыт каждый день. Вход на том же устройстве поддерживается, но он здесь
запасной путь, а не главный.

## Passkeys

Самое близкое по ощущению решение: тот же сценарий «QR на экране — подтверждение с телефона».

<Note>
  **Passkeys устойчивы к фишингу по построению — это более высокая планка безопасности.** Там,
  где она нужна, passkeys и следует брать. Veriqa даёт сопоставимое удобство для более простых
  сценариев.
</Note>

Где Veriqa выигрывает:

* **ничего не нужно заводить заранее** — пользователю не создают ключ, он подтверждает в
  мессенджере, который у него уже есть;
* **работает там, где кросс-девайсные passkeys ломаются**: выключен Bluetooth, виртуальная машина,
  удалённый рабочий стол, разные экосистемы у компьютера и телефона;
* **это не только вход**: второй фактор, привязка канала, подтверждение чувствительного действия
  и журнал аудита — одним механизмом.

## Встроенные виджеты входа мессенджеров

У Telegram и других есть собственные кнопки входа, и они бесплатны. Разница не в цене:

* **один слой интеграции на все каналы и почту** вместо отдельного виджета под каждый мессенджер;
* **полноценный OpenID Connect вместо JS-виджета**: токены, сессии, связывание учётных записей —
  вашей auth-системе не нужно понимать, что такое мессенджер;
* **мессенджер не обязан стоять на той поверхности, откуда входят**. Виджет предполагает, что
  приложение и мессенджер на одном устройстве; у Veriqa это принципиально разные устройства;
* сверх входа — второй фактор, привязка канала и журнал аудита.

## SMS-коды

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

## Device flow (RFC 8628)

Стандартный ответ на вопрос «как войти на устройстве без клавиатуры»: устройство показывает код,
пользователь вводит его на другом устройстве и подтверждает вход.

Отличие в том, **что делает пользователь на втором устройстве**. В device flow он открывает
браузер, идёт на страницу провайдера, вводит код и аутентифицируется — то есть проходит обычный
вход со всеми его шагами. В Veriqa он тапает по одному сообщению в мессенджере, где уже
авторизован.

Device flow остаётся правильным выбором там, где второе устройство не связано с мессенджером и
нужен строго стандартный механизм. Veriqa выигрывает там, где важна скорость и отсутствие
повторного логина.

## Где Veriqa не подойдёт

* **нужна планка безопасности уровня фишинг-резистентности** — берите passkeys или аппаратные
  ключи;
* **у аудитории нет ни одного из поддерживаемых мессенджеров и почты** — механизму не на что
  опереться;
* **нужен federated sign-out**: end-session-эндпоинта нет;
* **требуется антифрод**: признак «отправитель — бот» Veriqa отдаёт, но это дешёвый фильтр, а не
  система противодействия мошенничеству.


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