Insights

Як це робиться: ВХІД

Привіт! У цій серії ділюся робочими спостереженнями про прості й недооцінені речі, на яких спотикаються сучасні менеджери та власники.

Перші шукають правильну логіку. Другі воюють із залученням, утриманням і тим самим «ідеальним UX».

Сьогодні віддаю логіку входу для сайту чи мобільного застосунку. Безкоштовно.

Чому Google?

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

Один із найпростіших варіантів — вхід через Google.

Плюси:

•Готова ідентифікація акаунта. Не треба будувати весь вхід з нуля. Але Google-акаунт — не сертифікат «перед нами точно жива людина».

•Дані профілю. Ім’я й аватарка, якщо вони наявні та повернуті провайдером.

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

•Реалізація. Зрозумілий шлях з офіційними бібліотеками.

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

Який спосіб входу обрати?

Просто повірити клієнтському коду? Ні, дякую. Сервер має перевірити ID-токен: підпис, видавця, призначення для вашого застосунку та строк дії.

Серверна обробка входу й сесії? Так. Особливо коли працюєте з CRM та чутливими даними. Сам факт наявності сервера ще нічого не захищає — перевірки треба реалізувати.

Google One Tap? Зручно, коли потрібен швидкий сценарій. Але несподіване вікно може створити той самий «фактор ненависті». Не лякайте людей власним UX.

Дані: починайте з малого

Налаштовуючи scopes, розумійте, навіщо вам кожен дозвіл. Не збирайте інформацію «бо можна». Це чужа приватність, яку вам довірили.

1. Беріть тільки потрібні дані базового профілю.

2. Вік, стать чи додаткові відомості запитуйте лише за реальної потреби. Звичайний вхід сам собою їх не видає.

3. Додаткові дозволи просіть у момент, коли можете пояснити користувачу їхню користь.

Та сама аватарка

Навіщо вона? Щоб людина впізнала свій акаунт і відчула, що зайшла туди, куди треба.

МОЖНА КОПІЮВАТИ: якщо для продукту потрібна власна копія, отримайте доступну аватарку під час реєстрації й збережіть у своєму сховищі. При наступному вході перевірте, чи вона змінилася. Змінилася — оновіть. Немає фото — покажіть запасний варіант.

Не забудьте включити цю копію до правил зберігання та видалення даних.

База, приватність і таблиці

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

І не звалюйте все в одну купу.

•Відгуки користувача? Окрема таблиця.

•Метадані? Окрема структура там, де це виправдано.

•Коментарі? Таблиця та зв’язок із користувачем.

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

Просунутий рівень: що легко пропустити

1. Зв’язування акаунтів. Пошта з паролем і Google мають вести в один акаунт, коли це справді одна людина. Але збігу email недостатньо для безумовного об’єднання. Підтвердіть контроль обох способів входу; Google-ідентичність зв’язуйте через стабільний `sub`, а не мінливу адресу. Час останнього входу оновлюйте окремо.

2. Токени й сесії. ID-токен підтверджує ідентичність; access token дає доступ до API. Не плутайте їх. Серверна сесія, наприклад у Redis, або правильно налаштована сесія з JWT — вибір залежить від архітектури. Cookie має бути захищеною; назва JWT сама по собі безпеки не додає.

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

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

Забрати продукт