Разработка авторизации через номер телефона с SMS-кодом
SMS-авторизация выглядит просто: запросил код, получил SMS, ввёл, вошёл. На практике здесь больше edge cases, чем в любом другом методе входа. Неверный формат номера для одной страны, лимиты провайдера SMS, устаревшие коды из-за задержки доставки, подбор кодов без rate limiting — всё это встречается в продакшене. За 5+ лет мы реализовали SMS-авторизацию в 30+ проектах и знаем, как обойти каждый подводный камень.
Ввод и валидация номера телефона
Главная проблема — форматы номеров. Российский номер может быть введён как +7 999 123-45-67, 89991234567, 7 (999) 123-45-67. Сервер должен принимать всё это и нормализовывать в E.164 формат (+79991234567). На клиенте — использовать библиотеку libphonenumber (Google), она же используется в Android системно. Для iOS — PhoneNumberKit (Swift-обёртка над libphonenumber).
Поле ввода номера: keyboardType = .phonePad (iOS) / inputType="phone" (Android). Не numberPad — тогда нет кнопки +. Форматирование номера в реальном времени (маска) реализуем через UITextField delegate / TextWatcher — пользователь видит +7 (999) 123-45-67 по мере ввода, хотя хранится E.164.
Выбор кода страны — либо popup с флагами и поиском (полноценный компонент, 3-5 дней работы), либо жёстко заданная страна если приложение работает только в одном регионе.
OTP-экран: ввод кода
Кастомный OTP-input — 4 или 6 отдельных TextField-а с автоматическим переходом фокуса при вводе каждой цифры. На iOS textContentType = .oneTimeCode включает автоподстановку из SMS — iOS парсит SMS и предлагает код над клавиатурой. Это обязательная функциональность, пользователи ожидают её.
На Android SMS автоматически читается через SmsRetriever API (без запроса разрешений) или SMS User Consent API (с запросом). SmsRetriever требует специального хэша в тексте SMS, который генерируется на основе подписи APK. При смене keystore или debug/release build — хэш меняется, SMS не читается автоматически.
// Android — SmsRetriever val client = SmsRetriever.getClient(context) val task = client.startSmsRetriever() task.addOnSuccessListener { // Регистрируем BroadcastReceiver на получение SMS } Таймер обратного отсчёта для повторной отправки — стандарт 60 секунд. Без него пользователи спамят кнопку «Отправить снова» и засоряют очередь SMS-провайдера. Кнопка недоступна до истечения таймера, потом активируется.
Какой провайдер SMS выбрать для российского рынка?
Выбор влияет на доставляемость и стоимость. Firebase Auth — бесплатный лимит, простая интеграция, но не работает без Google Services, и в РФ наблюдаются перебои. Twilio Verify — высокая доставляемость глобально, но дороже российских провайдеров и неудобен для рублёвых счетов. SMS.ru / SMSC / Devino — низкая цена для РФ, рублёвые счета, но нет SDK, только HTTP API. Для российского рынка чаще всего выбирают SMS.ru или SMSC с собственным backend-сервисом: клиент никогда не знает API-ключ провайдера, запрос кода идёт на ваш сервер, сервер отправляет SMS. На backend — rate limiting: не более 3 кодов на номер в час, не более 5 попыток ввода на один код.
Что делать, если SMS не доходит?
Первым делом проверьте rate limits провайдера — часто проблемы в превышении лимитов. Второе — предусмотрите альтернативный канал: голосовой звонок с кодом (TTS). Третье — увеличьте TTL кода до 10 минут и покажите таймер обратного отсчёта, чтобы пользователь не нажимал повторно. В крайнем случае — подключите резервного провайдера. В нашей практике это решало проблему в 95% случаев.
Безопасность: что обязательно
- Код хранится на сервере в bcrypt-хэше, не в открытом виде.
- TTL кода: 5-10 минут, после истечения — код недействителен.
- После 3 неверных попыток ввода — блокировка сессии, нужно запросить новый код.
- Rate limiting по IP и по номеру телефона — защита от перебора и дорогостоящей SMS-спам атаки.
Что входит в работу
- UI экранов: ввод номера с маской, OTP-поле с автоподстановкой (iOS/Android)
- Интеграция с SMS-провайдером (Firebase, Twilio, SMS.ru, SMSC) через ваш backend
- Настройка rate limiting и безопасности на сервере
- Разработка альтернативного канала (голосовой звонок) — опционально
- Тестирование edge cases: невалидный номер, истёкший код, отсутствие SMS, смена сети
- Документация API и конфигураций
Сроки и опыт
Сроки: от 1 до 2,5 недель в зависимости от количества провайдеров и сложности UI. Более 5 лет на рынке мобильной разработки, выполнено 30+ проектов с авторизацией. Используем проверенные решения — Firebase, Twilio, собственные backend-микросервисы. Гарантируем безопасность согласно OWASP Mobile Top 10.
Чтобы обсудить детали вашего проекта и получить консультацию, свяжитесь с нами — подберём оптимальное решение под ваш стек и регион.