Реалізація системи авторизації та профілів користувачів

Реалізація системи авторизації та профілів користувачів

Гра без збереження прогресу на сервері — це проблема при першій переустановці чи смены пристрою. Гравець пройшов 30 рівнів, втратив телефон — та все з нуля. Для casual-гри це критично. Для мідкор з платними апгрейдами — втрата прогресу після покупки створює чарджбек та негативний відзив у сторі.

Серверна авторизація + cloud save — це не «фіча для великих ігор». Це базова гігієна для будь-якого проекту з монетизацією.

Архітектура авторизації: що вибрати

Guest account (Device ID) → Upgrade to Full Account. Паттерн, який максимально знижує бар'єр входу. Гравець запускає гру без реєстрації — створюється гостьовий аккаунт, прив'язаний до Device ID / Apple IDFA / Android GAID. Прогрес зберігається. При бажанні — конвертує у повний аккаунт (email, Apple Sign In, Google Play Games).

Ключовой момент — account merge: у гравця може бути гостьовий аккаунт на одному пристрої та повний аккаунт на іншому. Потрібна логіка об'єднання: який прогрес «перемагає»? Звичайно беремо старший або той, де вищий рівень. Це бізнес-рішення, яке потрібно прийняти заранее — не у момент першого баґу.

Federated Identity (Social Login). Sign In with Apple (обов'язковий для iOS якщо є інші social logins), Google Play Games (Android), Facebook, Steam. Не потрібно зберігати паролі — провайдер бере аутентифікацію на себе. Отримуємо JWT-токен, перевіряємо його підпис на сервері, видаємо власний session token.

Sign In with Apple — особливий випадок. Apple вимагає підтримки цього методу якщо у грі є хоча б один інший third-party login. Крім того, Apple може приховувати email користувача та видавати relay email. Це потрібно враховувати: не можна покладатися на email як унікальний ідентифікатор у Apple-користувачів.

Email + Password. Класика, але вимагає: зберігання паролів через bcrypt (не MD5 та не SHA1), rate limiting на login endpoint, secure password reset flow через email з time-limited токенами. У managed backend (PlayFab, Nakama) це є з коробки. У кастомному — потрібно реалізувати самостійно.

Структура Player Profile

Профіль гравця — не просто {username, email, level}. Правильна структура розділяє дані за типом та частотою оновлення:

Аккаунтні дані (persistent, рідко мінюються):

• playerId — внутрішній UUID, ніколи не мінюється
• email, username, avatarUrl
• linkedAccounts — масив прив'язаних провайдерів (google, apple, steam)
• createdAt, lastLoginAt

Ігровой прогрес (persistent, часто оновлюється):

• level, experience
• completedQuests[], unlockedContent[]
• inventoryId → посилання на окрему колекцію (інвентар може бути великим)
• statistics — kills, deaths, playtime, wins/losses

Сесійні дані (ephemeral, не зберігаються):

• Поточна позиція у матчі, тимчасові баффи, сесійна статистика — це у пам'яті сервера, не у БД

Розділення важливо для продуктивності: при вході у гру завантажуємо тільки аккаунтні дані та базовий прогрес. Інвентар на 200 предметів підгружаємо ліниво при відкритті інвентарного екрана.

Безпека: що не можна упустити

JWT validation на кожному запиту. Session token — JWT з підписю RS256 або HS256. Сервер перевіряє підпис та expiry при кожному API-візові. Строк дії — 24–48 годин, refresh token — 30–90 днів.

Server-side validation для економічних операцій. Додавання валюти, застосування промокодів, результат матчу — тільки через серверний код. Клієнт може показати результат оптимістично, але остаточне стан визначає сервер. Інакше — memory editor дають гравцю мільйон монет за 5 хвилин.

Rate limiting. Login endpoint: максимум 5 спроб на хвилину з одного IP. Це захист від brute force. У PlayFab та Nakama вбудовано. У кастомному — через Redis + sliding window.

Реальний кейс: казуальний раннер, Android+iOS. Спочатку — local save тільки. Після додавання монетизації (скини за IAP) — срочно потрібен cloud save. Додали PlayFab auth (Guest + Google Play Games + Apple Sign In) за 2 тижні. Проблема, яку не передбачали: частина гравців мала прогрес на Android під google-аккаунтом та пробували увійти на iPad — account merge виддав конфлікт. Потребував додаткового екрану «виберіть, який прогрес зберегти» + 3 дні додаткової роботи.

Процес реалізації

Починаємо з вибору identity provider та визначення Login Flow: Guest → Social → Email. Це UX-рішення з технічними наслідками.

Проектуємо схему даних профілю з обліком майбутнього росту (максимум предметів в інвентарі? система кланів?). Неправильна схема дорого обходится при масштабуванні.

Реалізуємо server-side validation для всіх економічних операцій — це не опціонально.

Тестуємо edge cases: втрата з'єднання під час збереження, дублювання аккаунтів при переустановці, expiry токена посередині ігрової сесії.

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