Розробка авторизації через номер телефону з SMS-кодом
SMS-авторизація виглядає просто: запросив код, отримав SMS, ввів, вошов. На практиці тут більше edge cases, ніж у будь-якому іншому методі входу. Невірний формат номера для однієї країни, лімити провайдера SMS, застарілі коди через затримку доставки, підбір кодів без rate limiting — все це трапляється в продакшені.
Ввід та валідація номера телефону
Головна проблема — формати номерів. Російський номер може бути введений як +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 (SMS) | Безплатний ліміт, проста інтеграція | Не працює без Google Services, обмеження в РФ |
| Twilio Verify | Висока доставляємість, глобальний | Дороже російських провайдерів |
| SMS.ru / SMSC / Devino | Низька ціна для РФ, рублеві рахунки | Нема SDK, тільки HTTP API |
| Яндекс 360 SMS | Інтеграція з екосистемою Яндекса | Обмежений охват |
Для російського ринку чаще всього SMS.ru або SMSC з власним backend-сервісом — клієнт ніколи не знає API-ключ провайдера, запит кода йде на ваш сервер, сервер відправляє SMS. На backend — rate limiting: не більше 3 кодів на номер у годину, не більше 5 спроб вводу на один код.
Безпека: що обов'язково
- Код зберігається на сервері в bcrypt-хеші, не у відкритому вигляді
- TTL кода: 5-10 хвилин, потім — код недійсний
- Після 3 неверних спроб вводу — блокування сесії, потрібно запросити новий код
- Rate limiting по IP та номеру телефону — захист від перебору та дорогостоючої SMS-spam атаки
Терміни: від 1 до 2,5 тижнів. Включає: UI екранів ввідуу номера та OTP, інтеграція з SMS-провайдером, автопідстановка кода (iOS + Android), тестування edge cases (невалідний номер, істекший код, нема SMS).