Skip to main content
Подтверждение происходит на телефоне, а инициатор ждёт на другом устройстве. Отсюда вопрос, который на обычном OIDC-провайдере не возникает: как инициатор узнаёт, что всё случилось? Способов три, и они не альтернативы друг другу, а разные уровни: возврат по redirect — обязателен всегда, живой статус и опрос — про то, что показывать пользователю, пока он ждёт.

​
1. Возврат по redirect_uri — основной путь

Итог входа приезжает так же, как в любом OIDC: браузер инициатора возвращается на redirect_uri с кодом авторизации, приложение меняет его на токены. Ничего специфичного для Veriqa здесь нет. Этого достаточно для веб-приложения на десктопе: страница входа сама доводит пользователя до возврата.
В query возврата приезжает iss (RFC 9207). Строгому relying party стоит сверять его со своим ожидаемым issuer — это дешёвая защита от подмены провайдера.

​
2. Живой статус — SignalR

Пока человек берёт телефон, сканирует код и нажимает кнопку, инициатор может показывать состояние: «ждём подтверждения», «подтверждено», «отклонено». Для этого есть хаб /hubs/auth — страница входа Veriqa использует его сама, и он же доступен вашей поверхности. Это то, что делает ожидание понятным на телевизоре или киоске, где пользователь не смотрит в адресную строку.

​
3. Опрос статуса — запасной путь

Там, где WebSocket недоступен (жёсткий прокси, ограниченная сеть, встроенное устройство), остаётся опрос:
Этот эндпоинт — про опрос состояния текущего входа. Подтверждение, которое создаёт ваш сервер, идёт отдельным входом: POST /api/transaction/confirmation создаёт транзакцию подтверждения (приложение аутентифицируется по client credentials и получает transaction_id с точкой входа для пользователя), а GET /api/transaction/{id}/result отдаёт её исход (токен приложения обязателен). Полный контракт — в API серверного подтверждения.Если в запросе создания передать include_channel_entries: true, ответ дополнительно несёт channel_entries — deep link с QR по каждому доступному каналу — рядом с единственным channel_entry, который остаётся прежним. Какие каналы попадут в список и в каком порядке, задаёт конфигурация показа каналов (включая запись ui_config), а не ваш запрос. Канал без адреса, который можно открыть, — например Email в Pull-режиме — в список не попадает, а если подтверждение настроено на веб-странице, массив пуст. Показать ли один вход из списка — решаете вы. response_valid_until тогда — самый ранний момент среди всех отданных входов.После исхода confirmed клиент, которому это разрешил интегратор, может получить и id_token подтвердившего — см. привязку с сервера.

​
Канал Email ведёт себя иначе

Важное для интегратора отличие: шаг веб-подтверждения зависит от канала.
  • на Telegram возврат /connect/authorize/callback сразу отдаёт редирект: человек уже нажал «да» в мессенджере;
  • на Email тот же адрес показывает страницу «Подтвердите вход» с формой — без её отправки кода не будет.
Причина: клик по ссылке из письма не доказывает, что за браузером тот же человек. Но интегратор, отладивший поток на Telegram, на Email упирается в «лишний» экран — это свойство канала, а не сбой.

​
Что после подтверждения

Поведение окна после успеха настраивается (закрыть, показать сообщение, автоматически продолжить) на стороне конфигурации входа — набором настроек, который владелец проекта или интегратор назначает клиенту. Само получение токенов от этого не зависит.

​
Дальше

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

Чем ТВ и киоск отличаются от десктопа.

Диагностика

Что означают отказы на callback.