Авторизація через Яндекс ID: де ламається вхід у застосунок
Авторизація через Яндекс ID виглядає як типовий сценарій: застосунок відкриває сторінку згоди, отримує код, обмінює його на пару токенів і далі живе із сесією.
Ламається це не на демонстрації, а на реальному життєвому циклі — коли система вивантажує процес, користувач змінює пароль або прилітає оновлення з магазину застосунків.
Перший клас збоїв — розсинхронізація сесії. Короткоживучий токен доступу минув, застосунок пішов у фон, і оновити його нічим: сховище токенів очистили або там залишився запис від попереднього встановлення. Формально вхід виконано, фактично кожен запит повертає відмову авторизації.
Другий — тихі відмови в частини користувачів. Не збігся адрес повернення після зміни ідентифікатора збірки, доступ відкликали в самому акаунті, на пристрої стоїть блокувальник — сервер відповідає помилкою обміну коду, а людина бачить білий екран або нескінченний індикатор.
Окремо б'є втрата сесії після оновлення: якщо токени лежать у звичайному сховищі, а не в захищеному, зміна підпису збірки робить їх нечитабельними.
Користувач отримує форму входу поверх порожнього профілю і повторний вхід в акаунт замість продовження роботи — разом із чернетками та налаштуваннями.
Ціна в усіх трьох збоїв одна: зростає частка відмов на вході в мобільний застосунок, а в логах видно обриви обміну без причини. Розбираємо, як це закривається — від схеми зберігання токенів до обробки кожного коду помилки.
Що змінюється після впровадження: швидкість входу та стійкість сесій
Після перенесення входу на зовнішнього провайдера — у нашому випадку Яндекс ID — частка успішних спроб перестає залежати від того, чи пам'ятає людина пароль.
У логах видно, як згортається число перерваних сценаріїв: натискання кнопки, підтвердження у знайомому застосунку, повернення в уже відкриту сесію. Там, де раніше помітна частина спроб закінчувалася скиданням пароля і повторним введенням, залишається один короткий шлях.
Час до першого екрана скорочується завдяки тому, що токен доступу лежить у захищеному сховищі пристрою.
При повторному запуску застосунок не ганяє користувача по формах, а відразу відновлює сесію — до відрисовки головного екрана минають частки секунди замість кола з введенням даних і очікуванням листа.
Продовження сесії йде у фоні: короткоживучий токен оновлюється за довгоживучим, і людина не випадає із застосунку посеред замовлення чи листування.
Якщо оновлення не проходить, сценарій деградує м'яко — застосунок просить повторне підтвердження, а не викидає на екран реєстрації з втраченими даними.
Окремий ефект — зниження звернень до підтримки щодо входу. Клас проблем «не надходить код», «скинувся пароль», «не пускає після оновлення» переходить на бік провайдера, і навантаження на першу лінію падає в рази. Конверсія реєстрації зростає рівно на ту частку, яку раніше з'їдала форма з паролем.
Порівняння схем входу: вбудоване вікно, браузер, серверний обмін
Схема входу в застосунок — це не лише екран з кнопкою: вона визначає, де живуть токени, хто може відкликати доступ і як поводитиметься сесія при зміні пароля в користувача. Нижче — три робочі схеми на OAuth 2.0 та обмеження авторизації, які кожна з них приносить у підтримку.
| Схема входу | Коли підходить | Що обмежує |
|---|---|---|
| Вбудоване вікно входу | Потрібен безшовний сценарій без виходу із застосунку, короткий шлях до основного екрана | Немає спільного контексту cookie та менеджера паролів, підтвердження пристрою недоступне — зростає частка зірваних входів і зауважень на перевірках безпеки |
| Вхід через зовнішній браузер | Основний сценарій: єдиний вхід між сервісами, збережені паролі та ключі доступу | Потрібне коректне повернення за universal link, обробка скасування та повторного входу |
| Серверний обмін даними | Довгі сесії, єдиний вихід, відкликання доступу та зв'язка з обліковим записом на бекенді | Потрібен свій сервер: секрет клієнта зберігається поза застосунком, з'являється стан сесії та логіка його відкликання |
Провайдер Яндекс ID дедалі частіше вважає вхід усередині застосунку небезпечним, тому вбудоване вікно залишаємо лише там, де безшовність важливіша за стійкість входу. Схема із зовнішнім браузером і кодом авторизації плюс PKCE дає SSO і не ламається на оновленнях системи.
Серверний обмін переносить отримання та продовження токенів на бекенд: вихід і відкликання доступу виконуються централізовано, а refresh-токени не лежать у відкритому сховищі на пристрої. Обмеження — потрібен свій сервер і акуратна робота зі станом сесії. На практиці частіше збираємо гібрид: вхід у зовнішньому браузері, обмін і продовження — на сервері.
Етапи інтеграції: від аудиту сценарію до передачі в підтримку
Порядок робіт жорсткий: поки сценарій входу не описаний до деталей, налаштування середовищ перетворюється на підбір параметрів навмання, а помилки спливають уже на релізі. Нижче — як проходить інтеграція авторизації через Яндекс ID.
Проєктування та перевірка
-
Аудит сценарію входу. Розбираємо поточні шляхи: гість, вхід за номером, вбудований або системний браузер. Уточнюємо, чи потрібен тихий повторний вхід і що робити при відмові або втраті мережі.
-
Схема обміну даними. Фіксуємо послідовність: запит авторизаційного коду, перевірка PKCE, обмін коду на токени, які дані йдуть на наш сервер. Окремо — зберігання, оновлення токенів і вихід з акаунта.
-
Налаштування середовищ. Окремі застосунки під розробку, тестовий контур і реліз, щоб тестові входи не змішувалися з бойовими. Прописуємо адреси повернення та строки життя сесії, ключі тримаємо поза репозиторієм.
-
Перевірка на пристроях. Матриця моделей і актуальних гілок системи: перший вхід, повторний, відв'язка акаунта, повернення з браузера. Дивимося, чи не розривається сесія при згортанні застосунку.
-
Навантажувальна перевірка. Одночасні входи, час обміну коду на токен, поведінка при недоступності провайдера. Відмова авторизації не повинна валити решту функціоналу.
-
Передача в підтримку. Віддаємо регламент: де дивитися журнали, які метрики входу вважаємо нормою, як діагностувати масові збої та відкотити конфігурацію до попередньої.
Що залишається в проєкті: схеми, налаштування, регламенти
Інтеграція закінчується не зеленим прогоном тестів, а пакетом артефактів, за яким команда працює далі без нас. Після запуску авторизації через Яндекс ID усе складаємо в репозиторій і вікі проєкту, із зазначенням власника кожного документа.
- Схеми входу — послідовності для першого входу, повторного та відкликання доступу: які стани проходить користувач і що показуємо на екрані.
- Конфігурації середовищ — набори параметрів для тестового та робочого контурів: адреси повернення, ключі, строки життя сесій, порядок синхронізації налаштувань.
- Правила доступу — хто із співробітників працює з панеллю провайдера та секретами, які ролі видані, як проходить ротація ключів.
- Документація з інтеграції — точки розширення: як додати сценарій входу, де змінюються тексти екрана згоди, які поля профілю надходять.
- Регламент підтримки — що моніторимо (частка неуспішних входів, помилки отримання профілю), які пороги вважаємо збоєм і кому ескалуємо.
- Порядок відкату — як повернути попередню версію сценарію входу, що відбувається з уже виданими сесіями і за який час повертаємося в робочий стан.
- Матриця помилок — відповідність відповідей провайдера і того, що в цей момент бачить користувач.
Пакет знімає залежність від автора інтеграції: новий інженер піднімає середовище і вносить правку за документацією, не розбираючи код з нуля.
Кейс: як скоротили частку відмов входу після зміни схеми
До переробки вхід ішов через вбудований браузер: користувач покидав застосунок, повертався за посиланням і на нестабільній мережі втрачав сесію.
Обмін коду на токен виконувався без повторів, тому 9,4% спроб входу закінчувалися помилкою, а підтримка приймала до 380 звернень на місяць із скаргою «не пускає» — при повністю справному акаунті.
Що змінили в схемі
Авторизацію через Яндекс ID перевели на нативний шлях: обмін коду на токени йде всередині застосунку, токен оновлюється у фоні до закінчення, а мережеві збої розбираються повтором із наростаючою паузою замість показу помилки.
Повернення із зовнішнього вікна більше не розриває потік — стан входу зберігається локально і відновлюється при наступному запуску.
| Метрика | До | Після |
|---|---|---|
| Частка невдалих входів | 9,4% | 1,6% |
| Час до першого екрана після входу | 6,8 с | 1,9 с |
| Звернення до підтримки щодо входу, на місяць | 380 | 90 |
| Частка користувачів на старих версіях застосунку | 21% | 6% |
Старі версії застосунку ми не відключали від попереднього шляху — інакше частина аудиторії просто не змогла б увійти.
Їм віддавали м'який екран оновлення і залишили запасну схему, тому частка таких користувачів знизилася з 21% до 6% без втрати встановлень і без зростання числа занедбаних сесій.
Що робити, якщо авторизація вже розгорнута на своїй стороні?
Так, розгорнутий вхід на своїй стороні — не перешкода.
Нова схема — авторизація через Яндекс ID — підключається поруч зі старою і працює одночасно з нею: на сервері з'являється друга точка перевірки відповіді, а в базі — прив'язка зовнішнього ідентифікатора до вже наявного акаунта.
Користувач при цьому нічого не втрачає: історія, підписки, налаштування та платіжні дані залишаються в його профілі.
Головне на цьому етапі — зв'язування записів. Коли людина вперше входить новим способом, ми зіставляємо її з наявним профілем за підтвердженим контактом і лише при неоднозначному збігу показуємо екран підтвердження. Так не з'являються дублі акаунтів і не губляться покупки, прив'язані до старого входу.
Переведення користувачів іде за групами, а не разом. Спочатку нова кнопка показується невеликій частці аудиторії поруч зі старою, ми дивимося частку успішних входів і відмов, і лише потім розширюємо охоплення.
Якщо частка помилок зростає, включення відкочується одним налаштуванням на сервері — оновлювати застосунок не потрібно.
Відмова від старого входу — останній крок, коли залишковий трафік падає до часток відсотка. На цей момент акаунти вже пов'язані, і тим, хто заходить рідко, вхід просто пропонується заново, без втрати даних.
Після відключення серверна частина старої схеми знімається, і в коді залишається один шлях авторизації — менше коду, менше точок відмови при підтримці.
Технічні сумніви: приватність, відкликання доступу, міграція
Дані назовні йдуть лише в межах тих областей доступу, які екран згоди показує явно, — ідентифікатор, відображуване ім'я, пошта. Усе понад це запитується окремо і обґрунтовується.
Нижче — розбір заперечень з етапу приймання: що бачить сторонній сервіс, як гаситься доступ і як це уживається з перевіркою магазинів.
Які дані користувача йдуть назовні?
Рівно ті, що перелічені у згоді: незмінний ідентифікатор, відображуване ім'я, адреса пошти — якщо він дозволений. Токени доступу зберігаються на нашому сервері, у застосунок потрапляє короткоживучий сеансовий ключ.
Як працює відкликання доступу?
Користувач відкликає згоду у своєму акаунті у провайдера — оновлювальний токен перестає діяти одразу, і застосунок дізнається про це на першому зверненні до профілю. Сесію на пристрої гасимо в той самий момент, фонові запити отримують відмову і не повторюються.
Чи пройде вхід перевірку в магазинах застосунків?
Так, за однієї умови: правила майданчиків вимагають альтернативного способу входу — пошта або телефон. Закладаємо його в інтерфейс на старті, тому повернень з модерації через авторизацію не буває.
Що таке частковий випуск і навіщо він потрібен?
Спочатку вхід отримує невелика частка аудиторії, далі розширюємо за часткою успішних спроб. При зростанні відмов розкатка зупиняється і відкочується одним кроком, не зачіпаючи вже видані сесії.
Що робити при втраті пристрою?
Вихід з усіх сесій гасить видані ключі, повторний вхід потребує підтвердження у провайдера. Копію пароля ми не зберігаємо — втрата пристрою не відкриває доступ до акаунта.
Обговоримо задачу: розберемо сценарій входу і повернемося з планом
Щоб обговорити задачу предметно, нам достатньо опису сценарію входу: де в застосунку з'являється кнопка «Увійти з Яндекс ID», чи є вже свій обліковий запис і як вона має зв'язуватися із зовнішнім.
Сам протокол авторизації — сценарій відпрацьований, тому оцінка та план робіт залежать насамперед від ваших деталей, а не від загальних питань.
- Опис сценарію входу — які екрани задіяні, що відбувається при першому вході та при повторному, чи потрібен гостьовий режим.
- Вимоги до облікового запису — які дані профілю запитуємо, де зберігаємо і хто має до них доступ.
- Схема зв'язування — як наявні користувачі об'єднуються з новим способом входу і що робити при збігу адрес.
- Доступи — тестовий і робочий контури застосунку плюс відповідальний за реєстрацію застосунку у провайдера.
- Пріоритети — які платформи закриваємо в першій ітерації, що переносимо в другу.
- Старт інтеграції — після узгодження плану підключаємо вхід і віддаємо збірку на перевірку.
- Підтримка після запуску — стежимо за часткою успішних входів і оновлюємо сценарій при зміні вимог провайдера.
По ходу обговорення закріплюємо відповідального: один інженер веде задачу від розбору сценарію до старту інтеграції та підтримки після запуску, тому вам не доведеться переказувати контекст різним людям.
