Этот путь нужен, только если кнопки «Войти через Telegram / WhatsApp / …» вы рисуете у себя, а
не отправляете пользователя на страницу входа Veriqa. Если кнопок у вас нет — читать эту страницу
не нужно, вам достаточно обычного подключения.
Зачем нужен bootstrap
Набор включённых каналов задаёт владелец проекта в Console и меняет когда угодно. Зашитый в код
список превращается в мёртвую кнопку: канал отключили — пользователь жмёт и попадает в никуда до
следующего передеплоя.
bootstrap — один GET на старте приложения, которым вы забираете актуальную конфигурацию
проекта вместо того, чтобы держать её у себя в конфиге. Это расширение Veriqa, а не стандартный
эндпоинт OIDC.
Без cloud key ответ содержит только публичные поля. Ответ — эффективная конфигурация для
конкретного client_id (значения проекта, суженные приложением), а не дамп настроек проекта.
Что в ответе
Два поля здесь рабочие, остальные — вспомогательные:
channels_enabled — ради него механизм и существует: это ровно тот набор кнопок, который
нужно показать сейчас;feature_flags — по ним вы решаете, показывать ли у себя step-up, привязку канала и
подтверждение операции.
Адреса эндпоинтов дублируют discovery и экономят один запрос на старте. ttl_seconds — срок
кэша ответа, по умолчанию 300 секунд; по истечении конфигурацию нужно перезапросить.
Стабильные поля контракта — channels_enabled и feature_flags. Стройте логику на них; на
остальные поля не завязывайте код, который будет дорого переписывать.Числовые лимиты, если они придут в ответе, — информационные: это не обязательство и не
замена защите на стороне облака.
Брендинга в ответе нет. Имя проекта, логотип, цвет и тему применяет сервер при отрисовке
страницы входа — интегратору они не нужны и в контракт не вынесены.
Поведение при сбоях
Чего bootstrap не гарантирует
Ответ bootstrap не обещает, что именно это увидит пользователь. Авторитетна серверная
резолюция на /connect/authorize: переданные ui_config и acr_values, а также
пользовательские переопределения могут дать другой итог.
