> ## 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.

# Поверхности входа

> Десктоп, Smart TV, киоск, устройство без клавиатуры: чем эти поверхности отличаются для интеграции и что поддерживается.

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

## Что работает сегодня

| Поверхность | Что показывает инициатор | Как узнаёт результат |
| - | - | - |
| Веб-приложение на десктопе | QR на странице входа | обычный redirect на `redirect_uri` |
| Десктопное приложение | QR в своём окне | redirect в системный браузер либо опрос статуса |
| Smart TV, приставка, киоск с браузером или webview | QR на экране | живой статус по SignalR либо опрос `GET /api/transaction/{id}/status` |
| Smart TV, приставка, киоск без браузера, у приложения есть бэкенд | QR из server-to-server входа подтверждения | бэкенд читает `GET /api/transaction/{id}/result` и обменивает подтверждённую транзакцию на `id_token` |
| Мобильное приложение | ссылка или QR | подтверждение в мессенджере на том же устройстве — запасной путь |

<Note>
  Если на устройстве есть браузер или webview, поверхности различаются только тем, **как инициатор
  узнаёт о завершении**: сам поток — тот же authorize → code → token. Если браузера нет, бэкенд
  приложения создаёт подтверждение и обменивает его на `id_token` пользователя — см.
  [Smart TV и поверхности без клавиатуры](/docs/ru/research/smart-tv). Для устройства без собственного
  бэкенда пути пока нет: полная реализация device flow сейчас в работе.
</Note>

## Поверхности без удобного ввода

Именно здесь кросс-девайсность окупается сильнее всего. На телевизоре, приставке или киоске ввод
пароля — это набор символов пультом; QR-код и подтверждение в телефоне снимают задачу целиком.

Для таких поверхностей полезны две вещи:

* **живой статус** — SignalR-хаб `/hubs/auth`, а там, где WebSocket недоступен, опрос
  `GET /api/transaction/{id}/status`;
* **контекст инициатора** — в сообщении подтверждения человек видит, что именно он подтверждает.
  Для киоска и общего устройства это важнее, чем для личного ноутбука: см.
  [Контекст инициатора](/docs/ru/concepts/initiator-context).

## Где инициатор — общее устройство

Киоск в офисе, терминал в зале, экран у входа: устройство общее, а подтверждает конкретный
человек. Здесь стоит держать в голове две вещи.

**Транзакция принадлежит сеансу, а не устройству.** Одноразовая кука между callback и authorize
привязана к последней загрузке страницы входа: если страница перезагрузилась, подтверждение
относится уже к другой транзакции, и Veriqa вернёт `browser_nonce_mismatch`. Это защита от
подтверждения чужой сессии — подробности в [Диагностике](/docs/ru/guides/troubleshooting).

**Показанный QR — секрет ровно на время транзакции.** На общей поверхности имеет смысл сокращать
время жизни экрана входа и не оставлять код висеть после завершения.

## Место как часть сценария

Привязка входа к **физическому месту** (QR на принтере или на выделенном экране в офисе) — предмет
исследования, см. [Место и личность](/docs/ru/research/place-and-identity).

## Что не зависит от поверхности

* набор каналов подтверждения — он про телефон пользователя, а не про инициатора;
* claims и их состав;
* требование к клиенту при входе через браузер: confidential-клиент с секретом либо public-клиент
  с PKCE S256. Server-to-server вход — только для confidential-клиента.


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