Розробка авторизації за номером телефону з SMS-кодом

SMS-авторизація в мобільному додатку: де ламається вхід

Вхід за номером телефону виглядає найпростішою формою авторизації, тому його рідко проєктують окремо.

Користувач чекає одноразовий код на телефон кілька секунд і, не дочекавшись, закриває додаток — повернути його потім дорожче, ніж одразу зробити первинну реєстрацію за номером передбачуваною.

Перший клас збоїв — недоставлений код. Повідомлення може зависнути на боці агрегатора, відсіктися фільтром оператора або загубитися при перемиканні з Wi-Fi на мобільну мережу.

Якщо логіка не розрізняє статуси «надіслано» та «доставлено», додаток показує хибне підтвердження і не дає повторити спробу.

Другий клас — дублі та гонки запитів. Користувач натискає кнопку двічі, додаток перезапускається, запит іде повторно — і на підтвердження номера телефону надходять два різні коди, валідний з яких лише останній.

Без ідемпотентної обробки та врахування часу життя коду такі звернення розбираються в підтримці вручну.

Третій клас — втрата сесії. Реєстрація за номером завершується успішно, але при зміні пристрою або мережі ключ доступу стає недійсним, і людина знову впирається в екран входу. Часто це наслідок занадто короткого строку життя сесії або її жорсткої прив'язки до каналу зв'язку.

Усі три класи відмов видно на клієнті, але виправляються вони на стику додатка, сервісу авторизації та SMS-шлюзу. Далі розбираємо, як це закривається — від схеми потоків до обробки помилок.

Що дає керований вхід за кодом: строки та надійність

Частка успішних входів визначається не серверною частиною, а кількістю кроків, які проходить користувач.

Коли код підставляється в поле автоматично з вхідного повідомлення, не потрібно згортати додаток і переписувати цифри вручну — на масовому потоці це піднімає частку завершених входів з 65–75% до 90%+, а час від запиту коду до входу вкладається в 15–25 секунд.

Надійність тримається на кількох речах: нормалізація номера до єдиного формату до відправки, відсікання віртуальних і корпоративних діапазонів там, де вони не потрібні, і автоматичне читання коду зі шторки сповіщень.

Повторні запити коду — головне джерело зайвих відправок і звернень у підтримку, тому на номер і на пристрій ставиться ліміт із наростаючою затримкою, а повторна відправка стає окремим сценарієм, а не кнопкою «надіслати ще раз».

Пікове навантаження тримаємо чергою: запити на відправку складаються в буфер, розподіляються по кількох маршрутах доставки — власні прямі підключення до операторів і агрегатор на кшталт Twilio як резервний канал.

Якщо один маршрут починає гальмувати або віддавати помилки, трафік іде на другий без участі користувача, а перевірка коду залишається ідемпотентною: повторна спроба підтвердження не створює дублів сесії.

У сумі це дає вхід, який не залежить від оператора, години пік і якості зв'язку в момент реєстрації: код приходить резервним каналом, якщо основний мовчить, а звернення в підтримку на тему «код не прийшов» йдуть з топу — замість ручного розбору залишаються метрики по кожному кроку та зрозумілий журнал доставки.

Порівняння схем входу: код за номером, пароль, посилання

Схема входу — це не один екран, а правила на всі випадки: новий пристрій, зміна номера, витік бази, відновлення доступу. Нижче порівняли варіанти, з якими приходять найчастіше: вони сумісні, і в одному додатку зазвичай працює комбінація з двох-трьох.

Другий фактор при вході не замінює основну схему, а надбудовується над нею. Відновлення доступу проєктуємо заздалегідь: резервний канал, строк життя одноразового коду, обмеження на кількість запитів.

Інакше користувач зі зміненим номером залишається без входу, а підтримка отримує потік ручних підтверджень.

Схеми сумісні: пароль залишаємо для старих акаунтів, безпарольний вхід включаємо для нових, а код підключаємо точково. На оцінці дивимося на вашу аудиторію та сценарії й пропонуємо набір, який закриває їх без зайвих кроків.

Як ми впроваджуємо вхід за кодом: від аудиту до приймання

Вхід за кодом ламається не в інтерфейсі, а на стику додатка, шлюзу та оператора: код не доходить, приходить двічі, відсікається антифродом. Тому кроки йдуть фіксованою послідовністю — на приймання виходить перевірений маршрут, а не демонстрація «ввели номер — побачили поле».

1. Аудит сценарію входу. Розбираємо екрани, стани та помилки: що показуємо при таймауті, що при невірному коді, куди повертаємо після скасування. Фіксуємо вимоги — довжину коду, строк життя, кількість спроб, поведінку при зміні номера на пристрої з двома SIM.
2. Схема потоків авторизації. Малюємо маршрути: перший вхід, повторний, зміна пристрою, відновлення доступу. Окремо — запасні варіанти: автозаповнення із системного сповіщення, повторна відправка, резервний канал доставки.
3. Налаштування відправки кодів. Підключаємо провайдерів, розподіляємо трафік, задаємо ліміти на номер, пристрій і адресу, налаштовуємо шаблони та правила перемикання при недоставці.
4. Перевірка на стенді. Прогоняємо сценарії скасування, блокування, закінчення коду, ручного введення та роботи без мережі, звіряємо статуси доставки на боці додатка та шлюзу.
5. Навантажувальна перевірка входу. Подаємо піковий потік реєстрацій, заміряємо час відгуку сервісу, частку доставлених повідомлень і поведінку черги при затримці оператора. Тут же калібруємо ліміти, щоб легітимні користувачі не впиралися в захист від підбору.
6. Приймання та передача. Віддаємо схему потоків, конфігурацію лімітів, тестові номери та чек-лист перед релізом, показуємо команді замовника розбір інцидентів за логами.

Далі зміни в сценарії входу йдуть тим самим маршрутом: правка схеми, перезбирання лімітів, прогін перевірок.

Що передаємо на руки: налаштування, схеми, регламенти

Передаємо не архів з вихідниками, а комплект, за яким чергова команда експлуатує вхід за кодом сама: без читання коду і без звернення до нас за кожною зміною ліміту. Склад такий.

• Конфігурація відправки кодів: шаблони повідомлень за мовами, підпис відправника, порядок провайдерів і правило перемикання на резервний при недоставці — відмова одного каналу не зупиняє вхід.
• Схема сценаріїв входу: діаграми первинної реєстрації, повторного входу, зміни номера та відновлення доступу, із зазначенням точок запиту коду та поведінки при закінченні його строку.
• Правила доступу та ліміти: таблиця ролей у панелі адміністратора, частота запитів на номер і на пристрій, тривалість блокування після серії невірних вводів. Ліміти лежать у конфігурації, а не в коді.
• Правила обробки номерів: формат зберігання, маскування в журналах і вивантаженнях, строк зберігання та порядок видалення за запитом користувача.
• Документація для підтримки: розбір типових звернень — код не прийшов, прийшов із запізненням, номер зайнятий, змінився оператор — із зазначенням, який параметр дивитися і що безпечно змінювати.
• Регламент розбору інцидентів: рівні, метрики доставки в зоні відповідальності чергового, порядок ескалації та форма звіту після збою.
• Передача доступів: перелік облікових записів і ключів із власниками, порядок ротації та відкликання при звільненні співробітника.

Такий комплект скорочує шлях від сигналу про проблему до рішення: черговий змінює параметр у конфігурації й бачить результат, не чекаючи складання нової версії.

Кейс: скоротили частку невдалих входів утричі

До нас прийшов сервіс доставки «Пульс» із завданням, яке виглядало вирішеним: вхід за номером телефону з кодом із повідомлення. За логами додатка до головного екрана доходило 62% тих, хто почав вхід, решта 38% кидали спробу на кроці введення. Підтримка отримувала звернення щодо входу майже в кожному сьомому інсталяційному сеансі.

Розбір шляху показав, що проблема не в самій SMS-авторизації, а в її реалізації.

Код не підставлявся автоматично, при згортанні додатка або перемиканні мережі стан кроку губився, а повторна відправка йшла на кожне натискання без обмежень — частина користувачів запитувала по 4-6 повідомлень, доходив останній код, і раніше введений вважався помилковим.

Що змінили

Звели підтвердження в один екран з автопідстановкою коду та наростаючою затримкою між повторними запитами.

Додали прийом коду з попереднього повідомлення, збереження стану кроку при поверненні в додаток, єдиний контур сесії між запусками та наскрізну телеметрію за кроками — тепер видно, де саме губиться користувач.

Частка успішних підтверджень номера зросла з 62% до 91%. Час до входу в додаток скоротився з 45 до 9 секунд на середньому пристрої. Повторні запити коду впали вдвічі, звернення в підтримку щодо входу — з 14% до 4% від кількості входів.

Той самий контур перенесли на інші продукти замовника: метрики тримаються, бо це не разова правка екрана, а набір правил обробки коду плюс спостережуваність за кожним кроком.

Чому SMS-код не доходить: діагностика частих збоїв

«Код не доходить» — майже завжди не одна причина, а конкретна ланка ланцюжка: додаток, сервер, постачальник розсилки, мережа оператора, пристрій. Поки ланки не розділені за журналами та статусами доставки, правки — вгадування.

Діагностика тримається на журналі: на кожен запит пишемо час відправки, статус від постачальника та підтвердження отримання пристроєм. Видно, де рветься — у нас, у постачальника чи в мережі оператора, — і правка йде в конкретну ланку.

Окремо закриваємо перебір: код живе обмежений час, кількість вводів на сесію скінченна, повторна відправка доступна не миттєво. Це ще й захист від лімітів — без нього обмеження оператора спрацьовують на живих людях, і авторизація відмовляє всім підряд.

Часті питання: ліміти, безпека, підтримка

Перед передачею проєкту замовники ставлять одні й ті самі питання: як вхід захищений від підбору коду, які ліміти на відправку, що відбувається при зміні номера та вході з нового пристрою. Нижче — короткі відповіді, спірні місця розбираємо разом з інженерами.

Які ліміти на відправку повідомлень?

Ліміт задається на номер і на пристрій: кілька повідомлень за інтервал, далі відправка відкладається. Масовий перебір номерів через форму входу не проходить, а витрати на повідомлення залишаються передбачуваними.

Що при зміні номера телефону?

Користувач підтверджує новий номер кодом, і тільки після цього прив'язка змінюється — старий залишається робочим на час підтвердження. Так доступ не губиться при втраті сімки або переоформленні номера.

Чи можна входити з кількох пристроїв?

Так, сесії прив'язані до пристрою, а не до номера: вхід на планшеті не завершує вхід на телефоні. У профілі видно список активних пристроїв із датою останнього входу, будь-яку сесію можна відкликати.

Що з підтримкою після впровадження?

Після запуску залишаємося на зв'язку: стежимо за часткою доставлених повідомлень і помилками входу, реагуємо на зміни на боці SMS-шлюзів та оновлення платформ. Допрацювання логіки входу йдуть тими самими етапами — правка, перевірка, випуск.

Обговоримо завдання та повернемося з планом і оцінкою

Щоб оцінка строків спиралася на факти, а не на припущення, перед стартом потрібні ввідні по чотирьох осях: наявні сценарії входу, пріоритет каналів верифікації, доступи та відповідальний за приймання.

Чим конкретніший цей набір, тим менше припущень у плані впровадження входу і тим чесніший склад робіт.

• Сценарії: реєстрація, вхід, відновлення доступу, зміна номера, вхід з нового пристрою — що йде в першу чергу.
• Пріоритет каналів: SMS як основний, резервний — голосовий виклик або повідомлення в месенджері, якщо код не дійшов.
• Доступи: тестовий контур додатка, репозиторій, кабінет SMS-провайдера, засоби моніторингу, якщо вже використовуються.
• Обмеження: платформи та мінімальні підтримувані версії, вимоги магазинів додатків до підтвердження номера.
• Відповідальний за приймання: хто затверджує тексти повідомлень, правила блокувань і підписує результат.
• Строк: дата, до якої вхід має працювати на бойовому контурі, і що можна винести в другу чергу.
• Аналітика: скільки спроб входу, яка частка відмов, чи є скарги на недоставку кодів.

У відповідь надсилаємо план впровадження входу: етапи, зміст кожного, що потрібно від вас і що вважається готовим. До нього — склад робіт і оцінка строків за етапами, а не однією цифрою: так другорядне можна зсунути, не рухаючи дату запуску. Окремо описуємо поведінку входу при недоставці коду та порядок відкату на попередній сценарій.

Наступний крок — розбір завдання: опишіть поточний сценарій входу, назвіть пріоритетні канали та потрібний строк. Повернемося з планом, складом робіт і оцінкою.