Skip to main content
Любой сценарий Veriqa собран из одного из двух механизмов. Для пользователя они выглядят одинаково — QR-код на экране или кнопка на телефоне, затем одно касание в мессенджере, — но транзакцию запускает разная сторона и возвращается разный результат.

​
Вход и регистрация

Обычный поток OpenID Connect. Ваше приложение отправляет пользователя на /connect/authorize, окно входа показывает QR-код (или кнопку канала на телефоне), пользователь подтверждает в мессенджере, а приложение обменивает код на токены в /connect/token.
  • Регистрация происходит тем же действием — ни формы, ни пароля, который нужно придумать.
  • Результат — id_token с sub, auth_time и запрошенными claims; сессию открываете вы.
  • Ваше приложение остаётся обычным OIDC-клиентом: без пакета Veriqa и SDK, только настройка.
Подробно: Вход и регистрация без пароля, Как работает auth-поток.

​
Серверная транзакция

Подтверждение, которое запрашивает ваш бекенд, — без входа и без редиректа браузера. Бекенд получает токен по Client Credentials, создаёт транзакцию запросом POST /api/transaction/confirmation для объявленного типа действия, показывает пользователю QR-код или ссылку из ответа и читает исход через GET /api/transaction/{id}/result.
  • Пользователь читает формулировку, объявленную на вашем хосте, с типизированными значениями слотов — «Удалить обращение A-900?», «Купить за 4.99 EUR?», — а не произвольный текст вызывающей стороны.
  • expected_identities разрешает подтвердить только конкретному человеку — например, владельцу текущей сессии.
  • Сессия не создаётся. Подтверждённую транзакцию при желании можно обменять на id_token подтвердившего.
Подробно: API серверного подтверждения.

​
Чем они различаются

Простое правило. Если результат — «пользователь вошёл», это вход. Если результат — «это действие одобрено», а выполняет действие ваш сервер, — это серверная транзакция.

​
Сценарии и их механизм

Рецепты всех сценариев входа собраны в Сценариях интеграции.