A Unity project: a casual runner on Android and iOS. Players go through 30 levels, buy skins with in-game currency and real money. After resetting the phone, progress disappears and purchases aren't restored — resulting in negative reviews, chargebacks, and a 40% drop in revenue. That situation is a clear sign: without server-side authentication and cloud save, monetization is wasted.
We design and implement authentication and profile systems for game projects on Unity, Unreal Engine, Godot. With 5+ years of experience and 30+ projects serving audiences from 10K to 1M+ users, we guarantee security, account merge, and scalability under load.
Which Authentication Architecture to Choose?
Guest account (Device ID) → Upgrade to Full Account. This pattern minimizes the entry barrier. The player launches the game without registration — a guest account tied to Device ID / Apple IDFA / Android GAID is created. Progress is saved. When desired, they convert to a full account (email, Apple Sign In, Google Play Games).
The key point is account merge: a player may have a guest account on one device and a full account on another. Logic for merging is needed: which progress "wins"? Usually we take the older one or the one with the higher level. This is a business decision that must be made upfront — not when the first bug appears.
Federated Identity (Social Login). Sign In with Apple (mandatory for iOS if other social logins exist), Google Play Games (Android), Facebook, Steam. No need to store passwords — the provider handles authentication. We receive a JWT token, verify its signature on the server, and issue our own session token. Compared to a custom system, integrating social login via PlayFab cuts development time by approximately 50% (from 4 weeks to 2 weeks). Using a ready-made backend speeds up implementation by 2 times.
Sign In with Apple is a special case. Apple requires this method if the game has at least one other third-party login. Additionally, Apple may hide the user's email and provide a relay email. This must be accounted for: you cannot rely on email as a unique identifier for Apple users. Apple Developer Documentation: Sign In with Apple
Email + Password. Classic, but requires: password storage via bcrypt (not MD5 or SHA1), rate limiting on the login endpoint (e.g., 5 attempts per minute from one IP), secure password reset flow via email with time-limited tokens. In managed backends (PlayFab, Nakama) this is built-in. In a custom solution — you need to implement it yourself.
What's Included in the Player Profile?
The player profile is not just {username, email, level}. A proper structure separates data by type and update frequency:
Account data (persistent, rarely changes):
-
playerId— internal UUID, never changes -
email,username,avatarUrl -
linkedAccounts— array of linked providers (google, apple, steam) -
createdAt,lastLoginAt
Game progress (persistent, frequently updated):
-
level,experience -
completedQuests[],unlockedContent[] -
inventoryId→ reference to a separate collection (inventory can hold up to 200 items) -
statistics— kills, deaths, playtime, wins/losses
Session data (ephemeral, not saved):
- Current match position, temporary buffs, session statistics — stored in server memory, not the database
Separation matters for performance: on game entry, we load only account data and basic progress. An inventory of 200 items is loaded lazily when the inventory screen is opened — this reduces loading time by 40%. On a project with 500,000 MAU, we thus reduced peak database load by 60%.
Why Security Is Critical?
JWT validation on every request. Session token — JWT with RS256 or HS256 signature. The server verifies the signature and expiry on every API call. Validity period — 24–48 hours, refresh token — 30–90 days.
Server-side validation for economic operations. Adding currency, applying promo codes, match result — only through server-side code. The client may show the result optimistically, but the final state is determined by the server. Otherwise, a memory editor gives a player a million coins in 5 minutes.
Rate limiting. Login endpoint: maximum 5 attempts per minute from one IP. This protects against brute force. Built-in in PlayFab and Nakama. In custom — via Redis + sliding window.
| Authentication Method | Integration Time | Features |
|---|---|---|
| Guest (Device ID) | 1–2 days | Low barrier, no recovery |
| Social Login | 3–7 days | Apple Sign In mandatory on iOS, relay email |
| Email + Password | 5–10 days | Requires bcrypt, rate limiting, password reset |
| Federated Identity | 2–4 weeks | Depends on number of providers |
How We Solved the Account Merge Problem on a Real Project
Real case: casual runner, Android+iOS. Initially only local save. After adding monetization (skins via IAP) — urgently needed cloud save. We added PlayFab auth (Guest + Google Play Games + Apple Sign In) in 2 weeks. The unforeseen problem: some players had progress on Android under their Google account and tried to log in on an iPad — account merge produced a conflict. An additional screen "choose which progress to keep" was needed, plus 3 days of refinement. Solution: on conflict, show both profiles, player chooses. Automatic — if level difference is greater than 5, take the higher one. This approach reduced support tickets by 30% and decreased player churn after device change by 15%.
Implementation Process
- Identity provider selection and Login Flow design: Guest → Social → Email. This is a UX decision with technical consequences.
- Profile data schema design with future growth in mind (number of items, clan system).
- Implementation of server-side validation for all economic operations.
- Testing edge cases: connection loss during save, account duplication on reinstall, token expiry during a game session.
- Deployment and support for 30 days.
What's Included in the Work?
- Auth flow architecture and data schema design
- Integration of guest auth, social logins, email/password
- Implementation of JWT tokens and refresh logic
- Server-side validation of all economic operations
- Documentation creation and access handover
- 30 days of support after deployment
| Task Scale | Estimated Timeline |
|---|---|
| Guest auth + basic cloud save (PlayFab/Nakama) | 1–2 weeks |
| Full auth (Social logins + email) + profile | 2–4 weeks |
| Custom auth system + JWT + PostgreSQL | 3–6 weeks |
| Account merge + migration from local save | 1–2 weeks |
Cost is calculated after requirements analysis. To get an estimate for your project, contact us — we will prepare a commercial proposal tailored to your stack and scope. Get a free consultation on authentication architecture.