Авторизация по звонку подходит для MVP SaaS, если пользователю нужно подтвердить номер телефона без ввода длинного кода из SMS. В этой статье разберём минимальный OTP-сценарий для малого бизнеса в Беларуси: регистрацию, вход, восстановление доступа, ограничения по попыткам и резервный канал. После чтения можно составить задачу для разработчика, определить API-интеграцию и проверить сценарий до запуска продукта.
Что включить в MVP авторизации по звонку?
В MVP достаточно закрыть три пользовательских действия: создать аккаунт, войти в него и восстановить доступ. Для каждого действия сервер отправляет запрос на авторизацию по номеру телефона, получает результат звонка и проверяет, что пользователь ввёл правильные цифры.
При Flash Call система звонит на указанный номер. Пользователь видит входящий вызов и вводит в форме контрольные цифры, например последние цифры номера. Сервер сравнивает введённое значение с ожидаемым и открывает сессию, если проверка пройдена. Сам звонок не нужно принимать, поэтому сценарий занимает меньше действий, чем голосовой код.
Для первой версии SaaS стоит сделать один экран с понятной последовательностью:
- Пользователь вводит номер телефона.
- Система проверяет формат номера и отправляет запрос на звонок.
- На экране появляется инструкция: «Посмотрите на номер входящего вызова и введите последние цифры».
- Сервер проверяет ответ и создаёт сессию.
- При ошибке пользователь получает ограниченное число повторных попыток.
Состояние операции лучше хранить отдельно от пользовательской сессии. У запроса должен быть собственный идентификатор, срок действия, статус и счётчик попыток. Тогда разработчик сможет отличить успешную авторизацию от просроченной, повторной или отменённой операции.
Как разделить регистрацию, вход и восстановление доступа?
Один и тот же способ подтверждения не должен автоматически открывать все возможности аккаунта. Сценарий зависит от действия пользователя: регистрация подтверждает владение номером, вход открывает существующий профиль, а восстановление требует более строгого контроля. Такой подход соответствует общему принципу выбора сценария подтверждения по цели операции (IBZ Source).
| Сценарий | Что проверить | Что сделать после успешного звонка |
|---|---|---|
| Регистрация | Свободен ли номер и не создаётся ли несколько аккаунтов | Создать профиль и предложить задать пароль или другой способ входа |
| Вход | Есть ли аккаунт и не заблокирована ли операция | Создать короткую сессию и записать событие входа |
| Восстановление доступа | Совпадает ли номер с аккаунтом и не изменились ли критичные данные | Разрешить смену пароля или запустить дополнительную проверку |
Для регистрации номер можно подтвердить один раз, после чего сохранить признак подтверждения. При входе каждый новый сеанс проходит отдельную проверку. При восстановлении доступа полезно завершать старые сессии и уведомлять пользователя о смене пароля через доступный канал.
Платёжные операции в MVP лучше не связывать только с авторизацией по звонку. Для изменения реквизитов, вывода денег или других чувствительных действий понадобится дополнительный фактор и отдельная проверка риска. Flash Call подтверждает доступ к номеру, но сам по себе не доказывает, что операцию выполняет владелец бизнеса.
Какие ограничения нужны до запуска?
Главная задача ограничений — не дать боту или злоумышленнику превратить авторизацию в поток звонков. Ограничения задают для номера, IP-адреса, аккаунта и устройства. Конкретные значения лучше подобрать после тестов, но сама логика должна появиться уже в первой версии.
- Ограничить число запросов на один номер за короткий промежуток времени.
- Ограничить число попыток ввода кода для одной операции.
- Повторно отправлять звонок только после паузы.
- Завершать операцию после истечения срока действия OTP.
- Временно блокировать повторяющиеся запросы с одного IP-адреса.
- Записывать в журнал успешные, ошибочные и отменённые проверки.
Одноразовый пароль обычно действует ограниченное время, часто 3–5 минут, после чего сервер должен отклонять его даже при правильном вводе (IBZ Source). Для Flash Call это означает, что контрольные цифры нельзя принимать бесконечно долго после звонка.
В ответах API не стоит сообщать, существует ли аккаунт с конкретным номером. Сообщение «Если номер зарегистрирован, мы отправили запрос» уменьшает риск перебора базы пользователей. Внутри системы причина отказа сохраняется подробно, а наружу возвращается одинаковый понятный ответ.
Как спроектировать API для Flash Call?
Для MVP достаточно разделить API на несколько операций. Названия могут отличаться, но смысл лучше сохранить:
start— создать операцию и отправить запрос на звонок;status— получить состояние операции;verify— проверить введённые цифры;resend— запросить повтор с учётом ограничений;cancel— завершить незакрытую операцию.
Клиентское приложение не должно самостоятельно решать, успешна ли авторизация. Оно показывает статус, который вернул сервер. Сервер же проверяет подпись или ключ API, связывает операцию с конкретным пользователем и создаёт сессию только после подтверждения от провайдера.
В базе данных достаточно хранить технический идентификатор операции, хеш номера или внутренний идентификатор пользователя, время создания, срок действия, число попыток и итоговый статус. Секреты API размещают в переменных окружения, а не в коде мобильного приложения или открытом репозитории.
Передача данных между приложением, SaaS-сервисом и API должна идти по HTTPS. Для личного кабинета, CRM и мобильного приложения также применяют учёт сессий, rate limiting и регулярный аудит настроек безопасности (IBZ Source). Для небольшого проекта это можно оформить как короткий чек-лист перед каждым релизом.
Что делать, если звонок не пришёл?
У авторизации по звонку должен быть резервный сценарий. Причина сбоя может находиться у оператора, на стороне устройства или в маршрутизации вызова. Пользователь не обязан разбираться, где именно возникла проблема.
| Ситуация | Действие интерфейса | Действие сервера |
|---|---|---|
| Звонок ещё обрабатывается | Показать статус и не давать сразу отправить новый запрос | Проверять статус по идентификатору операции |
| Истёк срок ожидания | Предложить повторить попытку | Закрыть старую операцию и создать новую |
| Проверка не пройдена | Показать нейтральную ошибку и оставить ограниченное число попыток | Записать событие и применить лимит |
| Канал недоступен | Предложить резервный способ подтверждения | Передать запрос в согласованный канал и сохранить связь операций |
Резервом может стать SMS, email или другой канал, который подходит конкретной аудитории. У каждого варианта свои ограничения: email доставляет код быстро, но письмо может попасть в спам; мессенджер обычно требует подключения к интернету; резервный канал повышает отказоустойчивость, но требует отдельной настройки (IBZ Source). Для SaaS лучше заранее определить, после какого сбоя появляется запасной вариант.
В интерфейсе не нужно обещать точное время звонка. Достаточно показать текущий статус, таймер операции и кнопку повторной отправки после паузы. Если продукт ориентирован на пользователей с простыми телефонами, инструкция должна работать без мобильного приложения.
Какие ошибки часто допускают в MVP?
- Считают успешным любой входящий звонок и не проверяют контрольные цифры на сервере.
- Хранят номер операции и секретный ключ в клиентском коде.
- Разрешают бесконечный повтор звонков с одного номера.
- Используют один сценарий для входа, восстановления доступа и чувствительных действий.
- Не показывают пользователю, что делать при пропущенном звонке.
- Не проверяют авторизацию на тестовых номерах, разных устройствах и при повторной отправке.
Отдельно проверьте защиту от автоматической регистрации. Flash Call может подтвердить доступ к номеру, но бот способен создавать много заявок, если API не ограничивает частоту. Практические меры для защиты регистрации с помощью этого механизма разобраны в материале о защите регистрации от ботов с помощью Flash Call.
Перед запуском MVP соберите таблицу сценариев: действие пользователя, канал, срок операции, число попыток, текст ошибки и результат. Затем проведите тест с реальными переходами «регистрация → выход → вход → восстановление». Если бизнесу нужен дополнительный канал или масштабирование, API-интеграцию авторизации по звонку можно вынести в отдельный модуль, чтобы не переписывать пользовательскую часть продукта при росте нагрузки.
3 шага, которые можно сделать на этой неделе:
- Описать три сценария: регистрация, вход и восстановление доступа.
- Добавить на сервере срок действия операции, лимиты и журнал событий.
- Проверить Flash Call на тестовых номерах и определить резервный канал для сбоя звонка.
