Sign in with Apple can succeed while the game still opens an empty profile instead of the existing Google-linked progress. Authentication has succeeded, but the game has mapped the identity to the wrong player record. Login bugs often sit between the identity provider, the local session and the game's account database.
Keep provider identity separate from the player profile
Give every game profile an internal identifier. Map a verified external identity to that record using the provider's stable subject and the relevant issuer or tenant scope. The display name and email address are profile attributes, not sufficient proof that two accounts belong to the same person.
A useful database model separates players, linked identities and sessions. An identity mapping needs a uniqueness constraint so the same provider identity cannot silently attach to two player profiles. Sessions should refer to the internal player rather than duplicating inventory and progression.
Object | Example responsibility | Failure to prevent |
Player record | Owns progress and game settings | Creating a new profile on every login |
External identity | Links a verified provider subject to a player | Merging accounts by a matching display name |
Game session | Authorises requests for a bounded period | Continuing to use a previous player's credentials |
Link operation | Records an explicitly approved association | Applying the same account merge twice |
Validate the token before using its claims
Decoding a JSON Web Token reveals its contents; decoding alone does not verify the signature. The backend must validate the provider's signature and expected issuer, audience and expiry, using a maintained verification library and the provider's supported key-discovery process.
Google's backend guidance explicitly warns against accepting a plain user ID submitted by the client. Apple also requires identity-token verification, including the nonce when used by the authentication flow. Configure the intended audience for each environment; accepting a development token in production can cross an isolation boundary.
A nonce binds a response to the authentication attempt that initiated it. Generate it with appropriate randomness and validate it according to the provider integration, including any required transformation. Do not substitute one fixed nonce shared across all users. For browser-based redirects, preserve and validate the flow's state and other protections required by the chosen protocol.
Prefer the provider's maintained SDKs and current implementation guidance. On Android, Credential Manager is relevant to current Sign in with Google flows. Copying a legacy sample without checking its API lifecycle can create a working prototype that is expensive to maintain.
Distinguish cancellation, missing credentials and server failure
A player dismissing the sign-in sheet has not entered an incorrect password. The absence of a previously authorised account is also different from a backend outage. Give each outcome a defined path instead of restarting the same automatic login repeatedly.
Credential Manager's Google sign-in guidance describes trying previously authorised accounts and handling a no-credential result with an appropriate broader account-selection flow. Do not interpret that result as evidence that the player's game profile was deleted.
If provider authentication succeeds but the game backend cannot establish a session, keep the existing recoverable local state. Show that account access could not be completed. Creating another guest profile at this point can make a temporary network error look like permanent loss of progress.
Design linking as a verified operation
Identify the currently signed-in game profile and explain what will be linked.
Obtain fresh proof of control of the identity being added.
Check whether that identity already belongs to another profile.
If two profiles exist, apply an explicit merge or selection policy.
Commit the mapping and any approved transfer atomically where possible.
Record the operation and return its durable result on a retry.
Suppose guest profile 301 has completed level 7, while linked profile 902 has completed level 24 and owns a permanent entitlement. Attaching the guest automatically can overwrite valuable state. Show the relevant progress and explain whether the action chooses one profile, merges allowed fields or requires support review.
An account merge needs rules for achievements, inventory, purchases, restrictions and social relationships. Adding balances can duplicate value. Clearing enforcement flags can let a merge bypass a restriction. Treat each category according to its ownership and history.
Prevent two simultaneous links from winning
A uniqueness constraint handles a case that a preliminary database lookup cannot solve. Two requests can both observe “identity not linked” before either writes. The database must enforce the invariant at commit, and the application must return a safe conflict result to the losing request.
Record a link-operation identifier and its intended source and destination. A retry after a lost response should retrieve the completed result. Do not repeat inventory movement simply because the interface never received the first success message.
Unlinking needs similar care. If it removes the player's only recovery method, require another verified method or explain the consequences before proceeding. Revoking a provider association and logging out current game sessions are separate actions that may both be needed.
Coordinate refresh and account switching
Several requests may discover an expired session at the same time. With 12 concurrent requests, 12 independent refresh attempts can race, particularly if refresh credentials rotate. A shared refresh coordinator can perform one refresh and let waiting requests use the resulting session, subject to their deadlines.
This is an illustrative concurrency count, not a required limit. The server also needs a defined refresh-token rotation and reuse policy. If a response is lost during rotation, recovery must follow that policy rather than blindly repeating an invalidated token.
Assign an account generation or equivalent ownership marker to in-flight work. If the user switches profiles while a request is running, its response must not populate the new account's screen or cache. Clear sensitive account-scoped data, and cancel or quarantine queued operations that belong to the old session.
Check release configuration when only store builds fail
A sign-in flow that works in development can fail after distribution because the release uses a different application identity or provider configuration. Compare the configured app identifiers, authorised clients and callback routes with the actual installed build. Inspect the provider's current setup requirements instead of changing token verification until an error disappears.
Test sign-in after backgrounding and process recreation as well as a simple uninterrupted flow. An authentication response that returns to a newly created screen still needs to match the original attempt. A stale callback must not attach an identity to whichever profile happens to be open now. Log a non-secret attempt identifier and a defined outcome code; never log the complete identity token to diagnose the mismatch.
Make recovery useful without weakening account control
Recovery should verify ownership through the available trusted methods. A public player name or a screenshot of an inventory is not strong proof by itself. Support workflows need access controls, audit records and a way to avoid leaking whether an unrelated person has an account.
Separate provider recovery from game recovery. If a player cannot access the Google or Apple identity they used, the game cannot simply bypass that provider's controls. It can use another previously linked method or a documented, evidence-based support process.
Test the whole login boundary
Accept a valid identity only in the intended audience and environment.
Reject an expired token and a replayed authentication attempt.
Cancel account selection without deleting local progress.
Link an identity already attached elsewhere and show a clear conflict.
Switch profiles while an old request is returning.
Lose a successful linking response and retry without repeating transfers.
Measure successful logins by completed game sessions, not merely provider callbacks. In an example cohort, 980 established sessions from 1,000 valid provider responses is a 98% completion rate for that stage. Analyse the remaining 20 by error category, while keeping cancellations and rejected invalid tokens out of an unrelated backend-reliability denominator.