Реализация системы авторизации и профилей пользователей

Реализация системы авторизации и профилей пользователей

Игра без сохранения прогресса на сервере — это проблема при первой же переустановке или смене устройства. Игрок прошёл 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 токена в середине игровой сессии.

Стоимость рассчитывается после анализа требований к авторизации и объёма данных профиля.