Где SaaS использует OTP
В SaaS подтверждение номера встречается в нескольких независимых пользовательских потоках. Их не стоит смешивать одним кодом и общим состоянием.
| Сценарий | Задача OTP | Пример purpose |
|---|---|---|
| Регистрация | Подтвердить номер нового пользователя | signup |
| Вход | Подтвердить доступ перед созданием сессии | login |
| Восстановление | Разрешить возврат доступа | recovery |
| Приглашение | Подтвердить получателя приглашения | invite |
| Смена номера | Проверить новый контакт | change_phone |
| Административное действие | Добавить шаг подтверждения риска | admin_action |
Поле purpose связывает код с конкретным действием. Значение при verify должно совпадать с send, иначе один код может ошибочно использоваться в другом потоке.
Регистрация с подтверждением номера
Не создавайте полноценный активный аккаунт только после нажатия кнопки «Зарегистрироваться». Сначала сохраните ограниченное состояние регистрации, отправьте OTP и активируйте пользователя после успешной проверки.
Хороший интерфейс показывает маскированный номер, канал, пятиминутный срок действия и таймер resend. Ошибка не должна раскрывать внутренние детали провайдера.
Passwordless-вход
Вход по одноразовому коду уменьшает необходимость помнить постоянный пароль, но требует аккуратной серверной сессии. После success: true создайте новую сессию, обновите идентификатор сессии и примените обычные правила устройства, ролей и времени жизни.
Нейтральный ответ на запрос отправки не должен сообщать, зарегистрирован номер или нет. Это снижает риск перебора аккаунтов.
Восстановление доступа
Поток восстановления отделяйте от входа собственным purpose. После проверки разрешайте только ограниченное действие: например, установить новый способ входа или восстановить доступ, а не выполнять произвольные операции от имени пользователя.
Для владельцев рабочих пространств и администраторов добавьте уведомление о восстановлении и возможность завершить другие активные сессии.
Подтверждение важных действий
OTP полезен как дополнительный шаг при:
- изменении платёжных реквизитов;
- выдаче административной роли;
- создании нового API-ключа;
- экспорте чувствительных данных;
- отключении средств защиты;
- смене владельца рабочего пространства.
Решение должно учитывать текущую сессию, роль, недавнюю аутентификацию и риск операции. Один OTP не заменяет проверку прав доступа.
Подключение Cascade
Бэкенд SaaS отправляет запрос с номером, каналом и purpose:
{
"phone": "77001234567",
"purpose": "login",
"channel": "telegram"
}
После ввода пользователем код проверяется с теми же phone и purpose. Bearer-токен хранится только в серверных секретах.
Пошаговые запросы описаны в инструкции подключения и справочнике API.
Стоимость пилота
WhatsApp и Telegram списывают по 3 кредита за успешную доставку. После регистрации начисляется 1000 стартовых кредитов. SMS предусмотрен, но публичный SMS-провайдер пока не запущен.
Для пилота выберите один-два ключевых потока и измеряйте:
- завершение регистрации;
- успешный вход после отправки;
- время от send до verify;
- resend на пользователя;
- ошибки кода и лимитов;
- кредиты на завершённое действие;
- обращения в поддержку.
Чеклист SaaS-команды
- Purpose различается для signup, login и recovery.
- API-ключ находится только на бэкенде.
- Код действует 5 минут и не используется повторно.
- Send, verify и resend имеют лимиты.
- Сессия создаётся только после успешного verify.
- Ответы не раскрывают наличие аккаунта.
- Административные действия проверяют права и риск отдельно.
- Есть метрики конверсии от отправки до завершённого действия.