Skip to main content
Телевизор, киоск, устройство с тремя кнопками: начать вход там, где вводить неудобно, и подтвердить в мессенджере на телефоне. Зачем это нужно и кому — на странице Smart TV и поверхности без клавиатуры. Здесь — что для этого есть в продукте сегодня.

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

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

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

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

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

Браузер или 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; обмен и его правила описаны в Привязке с сервера. Чем это отличается от входа через браузер:
  • Нет refresh_token. Транзакция погашается однократно; долгую сессию на телевизоре держит само приложение.
  • Это подтверждение, а не вход. Нужен объявленный action_type с текстовкой, а при включённом grant приложение узнаёт канальную идентичность подтвердившего в каждом подтверждении этого клиента. Для ТВ-сценария стоит завести отдельный клиент.
  • Контекст инициатора — то, что пишет ваш бэкенд. Запрос приходит с вашего сервера, а не с телевизора, а QR — вход на предъявителя: кто первым его откроет, тот и подтвердит, и sub будет его. Устройство и место кладите в текстовку типа действия через слоты, которые заполняет ваш бэкенд.
Client credentials — секрет приложения. Вызывайте серверный вход со своего сервера, а не из кода на устройстве: секрет, зашитый в приложение телевизора, извлекается.

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

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