User Authorization and Profile System Implementation

User Authorization and Profile System Implementation

Game without server-side progress save—problem at first reinstall or device change. Player beat 30 levels, lost phone—everything from scratch. For casual game this critical. For midcore with paid upgrades—progress loss after purchase creates chargeback and negative store review.

Server authorization + cloud save—not "feature for big games". This is basic hygiene for any monetized project.

Authorization Architecture: What to Choose

Guest account (Device ID) → Upgrade to Full Account. Pattern minimizing entry barrier. Player launches game without registration—guest account created, bound to Device ID / Apple IDFA / Android GAID. Progress saved. Optional—convert to full account (email, Apple Sign In, Google Play Games).

Key moment—account merge: player might have guest account on one device and full account on other. Need merge logic: which progress "wins"? Usually take older one or higher level. Business decision to make early—not at first bug.

Federated Identity (Social Login). Sign In with Apple (mandatory for iOS if other social logins), Google Play Games (Android), Facebook, Steam. No password storage needed—provider handles auth. Get JWT-token, verify signature on server, issue own session token.

Sign In with Apple—special case. Apple requires support if game has any other third-party login. Plus, Apple can hide email, issue relay email. Must account for: can't rely on email as unique identifier for Apple users.

Email + Password. Classic, but requires: password storage via bcrypt (not MD5 or SHA1), rate limiting on login endpoint, secure password reset flow with email and time-limited tokens. Managed backend (PlayFab, Nakama) have this out-of-the-box. Custom—implement yourself.

Player Profile Structure

Profile is not just {username, email, level}. Proper structure divides data by type and update frequency:

Account data (persistent, rarely change):

• playerId—internal UUID, never changes
• email, username, avatarUrl
• linkedAccounts—array of linked providers (google, apple, steam)
• createdAt, lastLoginAt

Game progress (persistent, frequent updates):

• level, experience
• completedQuests[], unlockedContent[]
• inventoryId—reference to separate collection (inventory can be large)
• statistics—kills, deaths, playtime, wins/losses

Session data (ephemeral, not persisted):

• Current match position, temporary buffs, session stats—memory on server, not DB

Division important for performance: on game start load only account data and basic progress. Load inventory lazily when opening inventory screen.

Security: What Not to Miss

JWT validation every request. Session token—JWT with RS256 or HS256 signature. Server checks signature and expiry on every API call. Duration—24–48 hours, refresh token—30–90 days.

Server-side validation for economy operations. Adding currency, applying promos, match result—only via server code. Client can show result optimistically, but final state determined by server. Otherwise—memory editor gives player million coins in 5 minutes.

Rate limiting. Login endpoint: max 5 attempts per minute from one IP. Brute force protection. Built-in PlayFab and Nakama. Custom—via Redis + sliding window.

Real case: casual runner, Android+iOS. Initially—local save only. After adding monetization (skins for IAP)—urgently needed cloud save. Added PlayFab auth (Guest + Google Play Games + Apple Sign In) in 2 weeks. Unexpected problem: some players had progress on Android under google-account, tried entering on iPad—account merge showed conflict. Required additional "select which progress to keep" screen + 3 days extra work.

Implementation Process

Start with identity provider choice and Login Flow definition: Guest → Social → Email. UX decision with technical consequences.

Design profile data schema accounting future growth (inventory item max count? clan system?). Wrong schema costly when scaling.

Implement server-side validation for all economy operations—not optional.

Test edge cases: connection loss during save, duplicate accounts on reinstall, token expiry mid-session.

Cost calculated after analyzing auth requirements and profile data volume.