Чувствительные действия — удаление важных данных, смена реквизитов, выдача кому-то доступа,
подтверждение платежа — стоит подтверждать заново, даже если пользователь уже вошёл. Veriqa
делает это одним нажатием в мессенджере, а не кодом из SMS.
Что отправляете
Новый authorize-запрос перед самим действием. Ничего специального в нём нет:
Что проверяете
Claim auth_time в id_token — момент завершения подтверждения. Свежесть определяете вы:
сравните auth_time с текущим временем и решите, укладывается ли он в приемлемое для этой
операции окно.
Не доверяйте своей локальной куке. Признак свежего подтверждения — auth_time из нового
id_token, а не наличие сессии в вашем приложении: сессия говорит лишь о том, что человек
когда-то вошёл.
max_age ядро не читает. Стандартный маркер OIDC max_age=0 посылать не вредно, но на
поведение Veriqa он не влияет — не стройте на нём логику. Механизм свежести здесь один: новый
authorize плюс проверка auth_time.
Почему это работает
Обходить нечего: долгоживущей сессии у issuer’а нет. Единственная кука между callback и authorize
одноразовая и снимается сразу при выдаче кода, поэтому каждый свежий authorize-запрос заново
спрашивает подтверждение в канале.
Усиление: два разных канала
Одну чувствительную операцию можно подтвердить в двух разных доверенных каналах — например
WhatsApp плюс почта. Сузить канал конкретного запроса помогает параметр acr_values:
Несколько значений разделяются пробелом — тогда пользователь выбирает из перечисленных.
Обогащение профиля попутно
Подтверждение — удобный момент, чтобы получить недостающие данные: если запросить scope=email
или phone, приложение получает верифицированный контакт прямо в ходе подтверждения, без
отдельной формы и отдельной проверки. Состав claims зависит от канала.
Чего для этого нет
- нет параметра «сценарий» — Veriqa не различает вход, step-up и подтверждение операции;
- нет серверной проверки свежести — окно приемлемости
auth_time задаёте и проверяете вы;
- отдельный транзакционный вход есть, но это не API для step-up.
POST /api/transaction/confirmation создаёт транзакцию подтверждения (приложение
аутентифицируется по client credentials и получает transaction_id с точкой входа для
пользователя) под объявленный тип действия и его типизированные слоты. Step-up на этой странице
собирается повторным authorize и работает без него.
