Разделите авторизацию по звонку на отдельные сценарии для клиента, курьера и сотрудника: у каждой роли свои действия, уровень доступа и правила повторной проверки. Сам звонок подтверждает контроль над номером, но не определяет, какие функции доступны пользователю. Ниже — схема, которая поможет описать путь каждой роли, назначить ей подходящие ограничения и проверить переходы между шагами до запуска.
Чем должны различаться сценарии для трёх ролей?
Начните с действий, для которых человек входит в систему. Клиенту обычно нужен доступ к личному кабинету или оформлению заказа. Курьеру — к заданиям и информации, нужной для доставки. Сотруднику — к рабочим функциям, соответствующим его должности. Авторизация подтверждает номер, а права на действия назначает приложение после проверки роли.
Не определяйте роль только по номеру телефона: один человек может пользоваться сервисом как клиент и работать в нём как курьер. После подтверждения номера система должна уточнить контекст входа или показать доступные роли. Для сотрудника заранее задайте, кто и каким способом подключает его рабочий профиль.
- Клиент: запрос кода или звонка появляется при входе или подтверждении действия.
- Курьер: после входа открываются только функции, связанные с выполнением заданий.
- Сотрудник: доступ зависит от назначенной рабочей роли, а не только от факта подтверждения номера.
Если курьер или сотрудник входит с нового устройства либо запрашивает чувствительное действие, предусмотрите дополнительное подтверждение. Не превращайте каждый обычный вход в длинную процедуру: отдельно перечислите события, при которых система повторно проверяет пользователя.
Как проходит авторизация по звонку?
В сценарии Flash Call пользователь вводит номер, получает короткий звонок, а система проверяет номер звонящего или последние цифры — в зависимости от выбранной интеграции. Пользователю не нужно слушать длинное сообщение или вводить код из SMS. После успешной проверки приложение связывает подтверждённый номер с выбранной ролью и открывает разрешённый раздел.
Опишите путь отдельно для каждого типа пользователя. Например: клиент вводит номер и подтверждает вход; курьер проходит те же шаги, затем попадает в рабочий интерфейс; сотрудник после проверки получает доступ в соответствии с назначенными правами. Эти примеры описывают структуру процесса, а не готовые правила доступа для конкретного сервиса.
Перед внедрением проверьте, что экран подсказывает, чего ждать: звонка или пропущенного вызова и способа подтверждения. Если звонок не поступил, покажите повторный запрос и резервный вариант. О том, как выстроить такой сценарий при недоступности клиента, подробнее рассказано в материале о резервной авторизации по звонку.
Какие ограничения и проверки добавить?
Ограничения должны препятствовать частым запросам, но оставлять человеку понятный путь к входу. Установите паузу между попытками, лимит повторов и срок действия подтверждения. Конкретные значения подбирайте по результатам тестирования и возможностям интеграции, а не копируйте одинаково для всех ролей.
Для клиента, курьера и сотрудника можно задать разные правила повторной проверки. Например, вход в обычный клиентский раздел и доступ к рабочим функциям могут требовать разных условий. При этом система должна сообщать, что делать дальше, если лимит исчерпан или звонок не распознан.
Проверьте сценарии подмены номера и не связывайте подтверждение с выдачей лишних прав. Разбор защиты от такой атаки есть в материале о защите авторизации по звонку от подмены номера. Для обработки ошибок доставки и истечения срока используйте отдельные тесты.
Как проверить сценарии до запуска?
Составьте таблицу проверок: роль, действие, ожидаемый экран, результат подтверждения и поведение при ошибке. Затем пройдите каждый сценарий на тестовом аккаунте. Убедитесь, что клиент не получает доступ к рабочим функциям, а курьер и сотрудник видят только предусмотренные для них разделы.
Проверьте не только успешный звонок. Запросите повторную попытку, дождитесь истечения срока подтверждения, проверьте недоступность звонка и неверный результат проверки. При необходимости протестируйте вход с одним номером в разных ролях. В рекомендациях по выбору каскада OTP отдельно подчёркнута важность проверки ошибок доставки и перехода на резервный канал.
Типичные ошибки:
- Система считает подтверждённый номер достаточным основанием для доступа ко всем функциям.
- Для клиента, курьера и сотрудника используют один экран без объяснения, какой профиль открывается.
- Команда проверяет только успешное подтверждение и пропускает истечение срока или повторный запрос.
- Лимит попыток срабатывает, но пользователь не видит, как продолжить вход.
- Новый рабочий профиль связывают с номером без проверки назначенной роли.
Начните с описания действий каждой роли и разрешённых ей разделов. Затем настройте отдельные правила подтверждения и протестируйте успешный вход, сбой звонка и повторную попытку. Такая карта поможет проверить авторизацию до подключения пользователей и точнее сформулировать требования к API-интеграции.
