> ## 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 и поверхности без клавиатуры

> Вход и подтверждение там, где вводить нечем: чем это отличается от device flow и что для этого уже есть в Veriqa.

Телевизор, киоск, устройство с тремя кнопками: начать вход там, где вводить неудобно, и
подтвердить в мессенджере на телефоне. Зачем это нужно и кому — на странице
[Smart TV и поверхности без клавиатуры](https://veriqa.app/whats-next/smart-tv). Здесь — что для
этого есть в продукте сегодня.

## Отношение к OAuth 2.0 Device Flow

Первый вопрос, который задают: не пересказ ли это RFC 8628. Нет — стандарт и Veriqa отвечают на
разные вопросы и живут на разных слоях.

| | RFC 8628 | Veriqa |
| - | - | - |
| На какой вопрос отвечает | как устройство без браузера получит токен | **чем** пользователь докажет, что он — это он |
| Что определяет | `device_code`, `user_code`, `verification_uri`, поллинг token endpoint | метод подтверждения — владение доверенным каналом |
| Про метод аутентификации | не говорит ничего: на `verification_uri` может быть что угодно, хоть пароль | это и есть его предмет |

Пересечение только по форме взаимодействия — «начни там, где неудобно вводить, подтверди на
телефоне». Протокольного дублирования нет: вход через браузер целиком живёт внутри
`authorization_code`, а server-to-server вход завершается собственным обменом на token endpoint.

## Что это даёт по сравнению с device flow

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

<Warning>
  Показ контекста инициатора **не является защитой от relay и MITM**. Мера вероятностная и
  работает через внимание пользователя. Усиление узкое; у голого device flow нет и его.
</Warning>

## Что есть сегодня

**Браузер или webview на устройстве.** Если платформа даёт webview, работает обычный вход через
`/connect/authorize`: страница с QR, подтверждение в мессенджере, приложение получает токены OIDC.

**Серверный вход подтверждения — без браузера.** Приложение вызывает
`POST /api/transaction/confirmation`, аутентифицируясь по client credentials и называя объявленный
тип действия (`action_type`), и получает в ответе
`channel_entry`: адрес для пользователя (`url`) — deep link канала или страницу выбора канала — и
тот же адрес готовой QR-картинкой (`qr`, PNG в data URI) со сроком показа (`valid_until`).
Показать эту картинку может приложение на любом TV-SDK — браузер на устройстве для этого не
нужен. Пользователь сканирует QR телефоном и подтверждает в мессенджере. Если в запросе передать
`include_channel_entries: true`, ответ дополнительно несёт `channel_entries` — deep link с QR по
каждому доступному каналу, — и экран может предложить выбор мессенджера.

QR-картинка несёт знак продукта: под кодом, ниже его quiet zone, идёт полоса «Powered by Veriqa»,
поэтому картинка выше, чем шире, — оставьте место для полосы, а не вписывайте изображение в
квадратную рамку. Полоса — часть того, что поставка выводит по лицензии: обрезать её технически
можно, а вправе ли вы это делать — вопрос лицензии, а не настройки.

Исход приложение забирает запросом `GET /api/transaction/{id}/result`: `confirmed`, `declined`,
`expired` или `failed`, пока ответа нет — `pending`. Если при создании переданы ожидаемые
идентичности (`expected_identities`), результат сообщает и то, совпал ли подтвердивший с
ожидаемым (`matched_type`).

**Вход без браузера, если у приложения есть бэкенд.** Получив исход `confirmed`, сервер приложения
обменивает транзакцию на `id_token` подтвердившего: `POST /connect/token` с
`grant_type=urn:veriqa:params:oauth:grant-type:confirmation`, `transaction_id` и `scope`, содержащим
`openid`. `sub` из токена сервер сохраняет рядом со своей учётной записью и открывает на телевизоре
собственную сессию. Клиенту нужны `AllowClientCredentials`, `AllowConfirmationTokenGrant` и `openid`
в `AllowedScopes`; обмен и его правила описаны в
[Привязке с сервера](/docs/ru/scenarios/channel-linking#привязка-с-сервера-без-входа).

Чем это отличается от входа через браузер:

* **Нет `refresh_token`.** Транзакция погашается однократно; долгую сессию на телевизоре держит само
  приложение.
* **Это подтверждение, а не вход.** Нужен объявленный `action_type` с текстовкой, а при включённом
  grant приложение узнаёт канальную идентичность подтвердившего в **каждом** подтверждении этого
  клиента. Для ТВ-сценария стоит завести отдельный клиент.
* **Контекст инициатора — то, что пишет ваш бэкенд.** Запрос приходит с вашего сервера, а не с
  телевизора, а QR — вход на предъявителя: кто первым его откроет, тот и подтвердит, и `sub` будет
  его. Устройство и место кладите в текстовку типа действия через слоты, которые заполняет ваш
  бэкенд.

<Note>
  Client credentials — секрет приложения. Вызывайте серверный вход со своего сервера, а не из кода
  на устройстве: секрет, зашитый в приложение телевизора, извлекается.
</Note>

## Чего сегодня нет

* **Пути для устройства без собственного бэкенда.** Секрет клиента нельзя держать на устройстве,
  поэтому TV-приложению без сервера до токенов пока не добраться. Полная реализация Device
  Authorization Grant (RFC 8628) сейчас в работе.
* **Нативных SDK под TV-платформы** нет: серверный вход и обмен — обычные HTTP-запросы.


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