SMS-код для двухфакторной аутентификации добавляет к паролю одноразовое подтверждение по телефону. В этой статье разберём, как спроектировать такой сценарий для сайта или приложения малого бизнеса: выбрать события, подготовить API-запрос, ограничить повторные попытки, обработать ошибки доставки и проверить путь пользователя. После чтения у вас будет понятная схема OTP-интеграции без привязки к конкретной CMS или языку программирования.
Что такое OTP и где он нужен интернет-магазину?
OTP расшифровывается как одноразовый пароль. Система создаёт короткий код, отправляет его в SMS и разрешает действие только после правильного ввода. Код действует ограниченное время и не подходит для следующего входа.
Для интернет-магазина SMS-подтверждение можно включить при входе в личный кабинет, восстановлении доступа, смене номера телефона или подтверждении важных действий с заказом. Выберите только те события, где дополнительный шаг действительно снижает риск чужого доступа. Если просить код при каждом просмотре каталога, часть покупателей просто закроет страницу.
Обычно сценарий выглядит так:
- Пользователь вводит номер телефона и пароль.
- Сайт создаёт одноразовый код.
- Приложение отправляет запрос в SMS API.
- Пользователь получает сообщение и вводит код.
- Сервер сверяет код, срок действия и число попыток.
- При успешной проверке сайт завершает вход или разрешает выбранное действие.
SMS-код подтверждает доступ к номеру телефона, но не заменяет пароль и другие меры защиты. Поэтому проверку нужно выполнять на сервере, а не в браузере. Клиентская часть только показывает поле для ввода и передаёт результат серверу.
Как подготовить SMS API для отправки одноразовых кодов?
Сначала определите, какие данные приложение передаёт сервису отправки: номер получателя, текст, идентификатор сообщения и параметры маршрута, если они предусмотрены API. В ответ система должна вернуть результат принятия запроса и идентификатор отправки. Этот идентификатор пригодится для журнала событий и разбора ошибок.
Отдельно настройте получение статусов доставки. Статус принятия API означает, что запрос обработан сервисом, но ещё не подтверждает получение SMS телефоном. Для контроля технической цепочки нужны отчёты о доставке, ошибки и время ответа. В практической интеграции через SMPP и API также разбирают DLR и повторы отправки: SMS о доставке через SMPP, DLR и повторы.
Текст сообщения делайте коротким и однозначным. Получателю достаточно знать код, срок его действия и название сайта или приложения. Например:
«Код входа в Личный кабинет: 482731. Никому его не сообщайте».
Не вставляйте в SMS пароль, содержимое заказа или длинные инструкции. Для транзакционного сообщения важнее, чтобы человек сразу понял, где применить код. Если один текст используется для разных действий, добавьте назначение: «Код для смены номера» или «Код подтверждения входа».
Какие параметры стоит предусмотреть в API?
- номер телефона в едином формате, который использует ваша система;
- текст сообщения с кодом и названием приложения;
- уникальный идентификатор операции;
- время создания запроса;
- статус отправки и статус доставки;
- понятный код ошибки для повторной обработки.
Ключ API храните на сервере или в защищённых настройках окружения. Не помещайте его в JavaScript-код страницы и мобильного приложения: пользователь сможет увидеть такой ключ через инструменты разработчика.
Как настроить проверку кода и защитить вход?
Сервер создаёт код случайным способом и связывает его с конкретным действием: входом, восстановлением доступа или сменой номера. При проверке он сравнивает введённое значение с ожидаемым, смотрит срок действия и проверяет, не использовали ли код раньше. После успешной проверки код нужно сразу пометить как использованный.
Ограничьте срок действия и число попыток. Точное значение зависит от сценария и требований к удобству, поэтому его лучше определить на тестовой группе пользователей. При превышении лимита сайт предлагает запросить новый код, но не показывает внутренние детали проверки.
Повторную отправку также нужно ограничить. Кнопка «Отправить ещё раз» должна становиться доступной после небольшой паузы, а сервер обязан проверять частоту запросов. Иначе один пользователь или автоматический скрипт сможет создать большое число SMS-запросов.
| Ситуация | Что видит пользователь | Что делает сервер |
|---|---|---|
| Код отправлен | Поле для ввода и сообщение о повторной отправке | Создаёт операцию и ждёт подтверждения доставки |
| Код введён верно | Вход или выбранное действие продолжается | Закрывает операцию и запрещает повторное использование |
| Код просрочен | Предложение запросить новый код | Отклоняет старое значение |
| Лимит попыток исчерпан | Временная блокировка проверки | Прекращает приём вариантов для этой операции |
| SMS не доставлено | Сообщение об ошибке и возможность повторить позже | Показывает технический статус и записывает причину |
Ответ сервера при ошибке входа формулируйте нейтрально. Не сообщайте, существует ли конкретный аккаунт, если пользователь ввёл чужой номер. Это уменьшает объём информации, который можно получить перебором запросов.
Как не потерять клиентов из-за SMS-подтверждения?
Пользователь должен понимать, что делать на каждом шаге. На странице укажите номер, на который отправлен код, но скройте часть цифр. Добавьте ссылку для исправления номера, таймер повторной отправки и понятный текст ошибки. Поле ввода не должно очищаться после каждой технической ошибки.
Проверьте сценарий на телефонах с разным качеством связи. SMS может прийти с задержкой, поэтому кнопка повторной отправки не должна появляться сразу. Если кодов пришло несколько, заранее определите правило: действительным остаётся последний отправленный код, а предыдущие прекращают действие.
Для мобильного приложения предусмотрите автоматическую подстановку кода, если операционная система поддерживает такую функцию. При этом ручной ввод должен оставаться доступным. На сайте полезно разрешить вставку кода из буфера, но сервер всё равно обязан проверять каждую попытку.
Какие ошибки чаще всего ломают OTP-интеграцию?
- Проверка кода в браузере. Пользовательская часть сайта не подходит для хранения логики подтверждения. Сверку выполняет сервер.
- Один код для всех действий. Код входа нельзя принимать для смены номера или восстановления доступа.
- Бесконечная отправка. Ограничьте повторные запросы и учитывайте ошибки API.
- Отсутствие статусов доставки. Ответ «принято» не равен факту доставки SMS. Подключите отчёты и журнал событий.
- Непонятный текст сообщения. Укажите назначение кода и не перегружайте SMS лишними словами.
- Нет тестов на сбои. Проверьте просроченный код, неверный ввод, задержку SMS, повторную отправку и недоступность API.
Для мониторинга полезно разделять ошибки сайта и ошибки отправки. Например, если пользователь запросил код, но API не ответил, это отдельный инцидент. Если API принял запрос, но доставка не подтверждена, разработчику нужен другой маршрут разбора. SMS-алерты о сбоях сайта и оплаты помогают выстроить такой контроль: как настроить SMS-алерты о сбоях сайта и оплаты.
Как проверить готовность интеграции перед запуском?
Начните с тестовой операции и пройдите весь путь вручную: запрос кода, получение SMS, правильный ввод, неверный ввод, повторная отправка и истечение срока. Затем проверьте, что один код нельзя применить дважды, а ошибка доставки не открывает доступ.
В отчётности отслеживайте хотя бы четыре показателя: число запросов, число принятых API-сообщений, статусы доставки и количество успешных подтверждений. Если запросов много, а подтверждений мало, причина может быть в тексте, задержке доставки, неверном формате номера или слишком коротком сроке действия кода.
Для малого бизнеса разумно запускать OTP с одного сценария, например входа в личный кабинет. После проверки логов и обращений клиентов можно подключить восстановление доступа или подтверждение изменения телефона. Техническую часть удобно вынести в отдельный модуль SMS API, чтобы правила проверки не были разбросаны по страницам магазина.
3 шага, которые можно сделать на этой неделе:
- Описать один сценарий подтверждения и все его ошибки на бумаге или в задаче для разработчика.
- Подключить отправку через SMS API, статусы доставки и журнал операций.
- Провести тесты с просроченным кодом, повторной отправкой и недоступным API, затем включить мониторинг.
