Розробка авторизації через номер телефону з SMS-кодом
SMS-авторизація виглядає просто: запросив код, отримав SMS, ввів, увійшов. На практиці тут більше edge cases, ніж у будь-якому іншому методі входу. Невірний формат номера для однієї країни, ліміти провайдера SMS, застарілі коди через затримку доставки, підбір кодів без rate limiting — все це зустрічається в продакшені. За 5+ років ми реалізували SMS-авторизацію в 30+ проектах і знаємо, як обійти кожен підводний камінь.
Введення та валідація номера телефону
Головна проблема — формати номерів. Український номер може бути введений як +38 099 123-45-67, 380991234567, 099 123-45-67. Сервер повинен приймати все це і нормалізувати у формат E.164 (+380991234567). На клієнті — використовувати бібліотеку libphonenumber (Google), вона ж використовується в Android системно. Для iOS — PhoneNumberKit (Swift-обгортка над libphonenumber).
Поле введення номера: keyboardType = .phonePad (iOS) / inputType="phone" (Android). Не numberPad — тоді немає кнопки +. Форматування номера в реальному часі (маска) реалізуємо через UITextField delegate / TextWatcher — користувач бачить +38 (099) 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.
Щоб обговорити деталі вашого проекту та отримати консультацію, зв'яжіться з нами — підберемо оптимальне рішення під ваш стек та регіон.