SMS-авторизация в мобильном приложении: где ломается вход
Вход по номеру телефона выглядит самой простой формой авторизации, поэтому его редко проектируют отдельно. Пользователь ждёт одноразовый код на телефон несколько секунд и, не дождавшись, закрывает приложение — вернуть его потом дороже, чем сразу сделать первичную регистрацию по номеру предсказуемой.
Первый класс сбоев — недоставленный код. Сообщение может зависнуть на стороне агрегатора, отсечься фильтром оператора или потеряться при переключении с Wi-Fi на мобильную сеть. Если логика не различает статусы «отправлено» и «доставлено», приложение показывает ложное подтверждение и не даёт повторить попытку.
Второй класс — дубли и гонки запросов. Пользователь нажимает кнопку дважды, приложение перезапускается, запрос уходит повторно — и на подтверждение номера телефона приходят два разных кода, валиден из которых только последний. Без идемпотентной обработки и учёта времени жизни кода такие обращения разбираются в поддержке вручную.
Третий класс — потеря сессии. Регистрация по номеру завершается успешно, но при смене устройства или сети ключ доступа становится недействительным, и человек снова упирается в экран входа. Часто это следствие слишком короткого срока жизни сессии или её жёсткой привязки к каналу связи.
Все три класса отказов видны на клиенте, но чинятся на стыке приложения, сервиса авторизации и SMS-шлюза. Дальше разбираем, как это закрывается — от схемы потоков до обработки ошибок.
Что даёт управляемый вход по коду: сроки и надёжность
Доля успешных входов определяется не серверной частью, а числом шагов, которые проходит пользователь. Когда код подставляется в поле автоматически из входящего сообщения, не нужно сворачивать приложение и переписывать цифры вручную — на массовом потоке это поднимает долю завершённых входов с 65–75% до 90%+, а время от запроса кода до входа укладывается в 15–25 секунд.
Надёжность держится на нескольких вещах: нормализация номера к единому формату до отправки, отсечение виртуальных и корпоративных диапазонов там, где они не нужны, и автоматическое чтение кода из шторки уведомлений. Повторные запросы кода — главный источник лишних отправок и обращений в поддержку, поэтому на номер и на устройство ставится лимит с нарастающей задержкой, а повторная отправка становится отдельным сценарием, а не кнопкой «отправить ещё раз».
Пиковую нагрузку держим очередью: запросы на отправку складываются в буфер, распределяются по нескольким маршрутам доставки — собственные прямые подключения к операторам и агрегатор вроде Twilio как резервный канал. Если один маршрут начинает тормозить или отдавать ошибки, трафик уходит на второй без участия пользователя, а проверка кода остаётся идемпотентной: повторная попытка подтверждения не создаёт дублей сессии.
В сумме это даёт вход, который не зависит от оператора, часа пик и качества связи в момент регистрации: код приходит по резервному каналу, если основной молчит, а обращения в поддержку по теме «код не пришёл» уходят из топа — вместо ручного разбора остаются метрики по каждому шагу и понятный журнал доставки.
Сравнение схем входа: код по номеру, пароль, ссылка
Схема входа — это не один экран, а правила на все случаи: новое устройство, смена номера, утечка базы, восстановление доступа. Ниже сравнили варианты, с которыми приходят чаще всего: они совместимы, и в одном приложении обычно работает комбинация из двух-трёх.
| Вариант входа | Когда подходит | Ограничения |
|---|---|---|
| Код по номеру | Мобильное приложение, номер уже в профиле, регистрация с нуля | Зависит от доставки сообщения; номер теряют или переносят; нужен лимит попыток |
| Логин и пароль | Старые аккаунты, вход с чужого устройства, веб-версия | Забытые и повторно используемые пароли; нужны правила сложности и сброс |
| Беспарольный вход по ссылке в письме | Редкие входы, возврат на компьютер, гостевой доступ | Переключение между почтой и приложением; задержка доставки; короткий срок жизни ссылки |
| Код как второй фактор | Перед оплатой, сменой номера, доступом к персональным данным | Лишний шаг на каждом входе, если включить его везде |
Второй фактор при входе не заменяет основную схему, а надстраивается над ней. Восстановление доступа проектируем заранее: резервный канал, срок жизни одноразового кода, ограничение на число запросов. Иначе пользователь со сменённым номером остаётся без входа, а поддержка получает поток ручных подтверждений.
Схемы совместимы: пароль оставляем для старых аккаунтов, беспарольный вход включаем для новых, а код подключаем точечно. На оценке смотрим на вашу аудиторию и сценарии и предлагаем набор, который закрывает их без лишних шагов.
Как мы внедряем вход по коду: от аудита до приёмки
Вход по коду ломается не в интерфейсе, а на стыке приложения, шлюза и оператора: код не доходит, приходит дважды, отсекается антифродом. Поэтому шаги идут фиксированной последовательностью — на приёмку выходит проверенный маршрут, а не демонстрация «ввели номер — увидели поле».
- Аудит сценария входа. Разбираем экраны, состояния и ошибки: что показываем при таймауте, что при неверном коде, куда возвращаем после отмены. Фиксируем требования — длину кода, срок жизни, число попыток, поведение при смене номера на устройстве с двумя SIM.
- Схема потоков авторизации. Рисуем маршруты: первый вход, повторный, смена устройства, восстановление доступа. Отдельно — запасные варианты: автозаполнение из системного уведомления, повторная отправка, резервный канал доставки.
- Настройка отправки кодов. Подключаем провайдеров, распределяем трафик, задаём лимиты на номер, устройство и адрес, настраиваем шаблоны и правила переключения при недоставке.
- Проверка на стенде. Прогоняем сценарии отмены, блокировки, истечения кода, ручного ввода и работы без сети, сверяем статусы доставки на стороне приложения и шлюза.
- Нагрузочная проверка входа. Подаём пиковый поток регистраций, замеряем время отклика сервиса, долю доставленных сообщений и поведение очереди при задержке оператора. Здесь же калибруем лимиты, чтобы легитимные пользователи не упирались в защиту от подбора.
- Приёмка и передача. Отдаём схему потоков, конфигурацию лимитов, тестовые номера и чек-лист перед релизом, показываем команде заказчика разбор инцидентов по логам.
Дальше изменения в сценарии входа идут по тому же маршруту: правка схемы, пересбор лимитов, прогон проверок.
Что передаём на руки: настройки, схемы, регламенты
Передаём не архив с исходниками, а комплект, по которому дежурная команда эксплуатирует вход по коду сама: без чтения кода и без обращения к нам за каждым изменением лимита. Состав такой.
- Конфигурация отправки кодов: шаблоны сообщений по языкам, подпись отправителя, порядок провайдеров и правило переключения на резервный при недоставке — отказ одного канала не останавливает вход.
- Схема сценариев входа: диаграммы первичной регистрации, повторного входа, смены номера и восстановления доступа, с указанием точек запроса кода и поведения при истечении его срока.
- Правила доступа и лимиты: таблица ролей в панели администратора, частота запросов на номер и на устройство, длительность блокировки после серии неверных вводов. Лимиты лежат в конфигурации, а не в коде.
- Правила обработки номеров: формат хранения, маскирование в журналах и выгрузках, срок хранения и порядок удаления по запросу пользователя.
- Документация для поддержки: разбор типовых обращений — код не пришёл, пришёл с опозданием, номер занят, сменился оператор — с указанием, какой параметр смотреть и что безопасно менять.
- Регламент разбора инцидентов: уровни, метрики доставки в зоне ответственности дежурного, порядок эскалации и форма отчёта после сбоя.
- Передача доступов: перечень учётных записей и ключей с владельцами, порядок ротации и отзыва при уходе сотрудника.
Такой комплект сокращает путь от сигнала о проблеме до решения: дежурный меняет параметр в конфигурации и видит результат, не дожидаясь сборки новой версии.
Кейс: сократили долю неудачных входов втрое
К нам пришёл сервис доставки «Пульс» с задачей, которая выглядела решённой: вход по номеру телефона с кодом из сообщения. По логам приложения до главного экрана доходило 62% начавших вход, остальные 38% бросали попытку на шаге ввода. Поддержка получала обращение по входу почти в каждом седьмом установочном сеансе.
Разбор пути показал, что проблема не в самой SMS-авторизации, а в её реализации. Код не подставлялся автоматически, при сворачивании приложения или переключении сети состояние шага терялось, а повторная отправка шла по каждому нажатию без ограничений — часть пользователей запрашивала по 4-6 сообщений, доходил последний код, и ранее введённый считался ошибочным.
Что изменили
Свели подтверждение в один экран с автоподстановкой кода и нарастающей задержкой между повторными запросами. Добавили приём кода из предыдущего сообщения, сохранение состояния шага при возврате в приложение, единый контур сессии между запусками и сквозную телеметрию по шагам — теперь видно, где именно теряется пользователь.
Доля успешных подтверждений номера выросла с 62% до 91%. Время до входа в приложение сократилось с 45 до 9 секунд на среднем устройстве. Повторные запросы кода упали вдвое, обращения в поддержку по входу — с 14% до 4% от числа входов.
Тот же контур перенесли на остальные продукты заказчика: метрики держатся, потому что это не разовая правка экрана, а набор правил обработки кода плюс наблюдаемость по каждому шагу.
Почему SMS-код не доходит: диагностика частых сбоев
«Код не доходит» — почти всегда не одна причина, а конкретное звено цепочки: приложение, сервер, поставщик рассылки, сеть оператора, устройство. Пока звенья не разделены по журналам и статусам доставки, правки — угадывание.
| Симптом | Причина | Что делаем |
|---|---|---|
| Код идёт минутами вместо секунд | Задержка доставки кода: очередь у поставщика или перегрузка канала | Подключаем резервный маршрут и переключаемся по статусу |
| Кода нет на номера одного оператора | Блокировка рассылки оператором из-за жалоб или шаблона | Согласуем текст и подпись, разносим трафик по двум поставщикам |
| Статус «доставлено», сообщения нет | Фильтр устройства или переполненный ящик | Дублируем голосовым вызовом, подсказываем, где искать |
| На один номер кода нет, на другие идут | Неверный номер телефона или формат записи | Нормализуем номер до международного формата до отправки |
| После нескольких попыток отправка встала | Лимит на отправку кодов на номер и устройство | Считаем попытки на сервере, держим паузу между ними |
Диагностика держится на журнале: на каждый запрос пишем время отправки, статус от поставщика и подтверждение получения устройством. Видно, где рвётся — у нас, у поставщика или в сети оператора, — и правка идёт в конкретное звено.
Отдельно закрываем перебор: код живёт ограниченное время, число вводов на сессию конечно, повторная отправка доступна не мгновенно. Это ещё и защита от лимитов — без неё ограничения оператора срабатывают на живых людях, и авторизация отказывает всем подряд.
Частые вопросы: лимиты, безопасность, поддержка
Перед передачей проекта заказчики задают одни и те же вопросы: как вход защищён от подбора кода, какие лимиты на отправку, что происходит при смене номера и входе с нового устройства. Ниже — короткие ответы, спорные места разбираем вместе с инженерами.
Как код защищён от подбора?
Код одноразовый и живёт несколько минут. Сервис считает неверные вводы: после нескольких попыток сессия сбрасывается, а номер получает блокировку с нарастающей задержкой. Дополнительно сверяется устройство, с которого запрошен код, — чужой ввод не проходит.
Какие лимиты на отправку сообщений?
Лимит задаётся на номер и на устройство: несколько сообщений за интервал, дальше отправка откладывается. Массовый перебор номеров через форму входа не проходит, а расход на сообщения остаётся предсказуемым.
Что при смене номера телефона?
Пользователь подтверждает новый номер кодом, и только после этого привязка меняется — старый остаётся рабочим на время подтверждения. Так доступ не теряется при утере симки или переоформлении номера.
Можно ли входить с нескольких устройств?
Да, сессии привязаны к устройству, а не к номеру: вход на планшете не завершает вход на телефоне. В профиле виден список активных устройств с датой последнего входа, любую сессию можно отозвать.
Что с поддержкой после внедрения?
После запуска остаёмся на связи: следим за долей доставленных сообщений и ошибками входа, реагируем на изменения на стороне SMS-шлюзов и обновления платформ. Доработки логики входа идут теми же этапами — правка, проверка, выпуск.
Обсудим задачу и вернёмся с планом и оценкой
Чтобы оценка сроков опиралась на факты, а не на предположения, перед стартом нужны вводные по четырём осям: существующие сценарии входа, приоритет каналов верификации, доступы и ответственный за приёмку. Чем конкретнее этот набор, тем меньше допущений в плане внедрения входа и тем честнее состав работ.
- Сценарии: регистрация, вход, восстановление доступа, смена номера, вход с нового устройства — что идёт в первую очередь.
- Приоритет каналов: SMS как основной, резервный — голосовой вызов или сообщение в мессенджере, если код не дошёл.
- Доступы: тестовый контур приложения, репозиторий, кабинет SMS-провайдера, средства мониторинга, если уже используются.
- Ограничения: платформы и минимальные поддерживаемые версии, требования магазинов приложений к подтверждению номера.
- Ответственный за приёмку: кто утверждает тексты сообщений, правила блокировок и подписывает результат.
- Срок: дата, к которой вход должен работать на боевом контуре, и что можно вынести во вторую очередь.
- Аналитика: сколько попыток входа, какая доля отказов, есть ли жалобы на недоставку кодов.
В ответ присылаем план внедрения входа: этапы, содержание каждого, что требуется от вас и что считается готовым. К нему — состав работ и оценка сроков по этапам, а не одной цифрой: так второстепенное можно сдвинуть, не двигая дату запуска. Отдельно описываем поведение входа при недоставке кода и порядок отката на прежний сценарий.
Следующий шаг — разбор задачи: опишите текущий сценарий входа, назовите приоритетные каналы и нужный срок. Вернёмся с планом, составом работ и оценкой.
