Отдельного API у сценариев нет. Ни параметра «сценарий», ни отдельного типа транзакции
Veriqa не знает. Поэтому рецепты даны на уровне HTTP — они одинаково воспроизводимы на .NET,
Node, Java и Python.
Сценарии
Вход и регистрация без пароля
QR на экране, подтверждение в мессенджере, регистрация тем же действием.
Вход и привязка канала
Одно действие — два результата: пользователь вошёл, продукт получил живой канал.
Второй фактор и step-up
Свежее подтверждение перед чувствительной операцией и проверка
auth_time.Замена SMS-кодов
Тот же поток без тарификации за сообщение и с полноценной аутентификацией.
Заявки без CAPTCHA
Верифицированный контакт и живой канал вместо адреса, введённого руками.
Восстановление доступа
Привязанный канал вместо цепочки писем и кодов.
Что можно передать в authorize
Чего в Veriqa для этого нет
Чтобы не искать несуществующего:- нет параметра «сценарий» в authorize-запросе — тип сценария Veriqa не знает и не различает;
- отдельный транзакционный вход есть, но он не про эти сценарии.
POST /api/transaction/confirmationсоздаёт транзакцию подтверждения (приложение аутентифицируется по client credentials и получаетtransaction_idс точкой входа для пользователя), однако различает он не сценарии, а объявленный ключ действия и его типизированные слоты. Сценарии этой страницы собираются повторным authorize и работают без него; - нет серверной проверки свежести — окно приемлемости
auth_timeзадаёте и проверяете вы; - нет клиентского SDK или виджета — «своя кнопка» это ссылка с нужными параметрами.
Дальше
OIDC + Veriqa: разбор
Где Veriqa встаёт в стандартный поток.
Настройка каналов
MAX, Telegram, WhatsApp, другие мессенджеры и Email.