RemapGoogleId() during AuthenticateGoogle() is not working for us after changing authentication from GPS V1 to GPS V2

Runtime Framework
1

We moved from depracated Google Play Services V1 to new version in our game. We had to change how our game is authenticating with Google Play Services: before the change, we used TokenID, now we use ServerAuthCode.

In order to authenticate from our game to Nakama, we had to add new google credentials flag to nakama configuration:

{"web":"client_id":"","project_id":"","auth_uri":"","token_uri":"https://oauth2.googleapis.com/token","auth_provider_x509_cert_url":"https://www.googleapis.com/oauth2/v1/certs","client_secret":"","redirect_uris":[""]}}'

We are using latest nakama version 3.26.

Now we encountered an issue, where user is getting new nakama account with new Google ID linked, despite logging from the same google account.

Old Google ID have different format: 113792687972591949640
New Google ID have a prefix: a_6368656850866412253

I found that there is a function for remapping old google Ids to new one:

But unfortunately, it’s not working for us. Can you please provide a solution to successfully remap old accounts to new ids or can you point me resources, which can shed new light on this issue?

Regards,
Michał

2

@MichalKrela the remapping looks at the originalPlayerId field to map the old id to the new one.

I believe this value may not always be available, but it is not clear to me when it is or isn’t depending on the Google auth scopes, flow, account details and etc.

Is the case that the value is coming back empty?

3

Hi @sesposito
thanks for answer. In our case, as you can see below, originalPlayerId is not populated in response json (don’t mind id is different from previous post, I checked this behavior on number of accounts):

{
    "kind": "games#player",
    "playerId": "a_3547597106375657482",
    "displayName": "SeemingDetention84",
    "avatarImageUrl": "https://lh3.googleusercontent.com/n2E1SEZhkLSgYX0vzRtXvUrc5D4DtNZKj4EFMX_Bk_-yY5Da9HKb4L2iG7tjajZY8RVr",
    "bannerUrlPortrait": "https://lh3.googleusercontent.com/iXNdw4kqPIpEFFF45s8f6rJUYW9J0-OxUI9VVP2dRlY06Kj99Qy0Qi0yGuq_IlGDGMqyZK5g3FlmD-GYqA",
    "bannerUrlLandscape": "https://lh3.googleusercontent.com/I2yadG1Gyqpk2rQNtW3GfJNNKjHXBuYLULmTPdvcvx6325gNhSo-B3jcpBRzBseeHKZnyf1EaG8aeHXd6yE",
    "profileSettings": {
        "kind": "games#profileSettings",
        "profileVisible": true,
        "friendsListVisibility": "REQUEST_REQUIRED"
    },
    "experienceInfo": {
        "kind": "games#playerExperienceInfo",
        "currentExperiencePoints": "0",
        "currentLevel": {
            "kind": "games#playerLevel",
            "level": 1,
            "minExperiencePoints": "0",
            "maxExperiencePoints": "1000"
        },
        "nextLevel": {
            "kind": "games#playerLevel",
            "level": 2,
            "minExperiencePoints": "1000",
            "maxExperiencePoints": "2500"
        }
    },
    "title": "Rookie",
    "gamePlayerId": "a_3547597106375657482"
}

Can you suggest any other workaround on this issue, other than remapping IDs?

Regards,
Michał

4

I found this: Next generation Player IDs  |  Android game development  |  Android Developers.

Next generation Player IDs will only apply to users who have never signed into your game with PGS. Existing users who have already logged into your game will continue to get the same Player ID.

My understanding is that accounts that have signed in and were assigned the old ID, should still observe it now, is that not the case?

On the Player payload spec:

originalPlayerId:

The player ID that was used for this player the first time they signed into the game in question. This is only populated for calls to player.get for the requesting player, only if the player ID has subsequently changed, and only to clients that support remapping player IDs.

If the originalPlayerId is not returned, I’m not sure how else to map an existing account on the old ID to the new one.

5

Hi,

to not left this topic unanswered, I’ll share what I found out (with special thanks to @rbretecher-voodoo)

I created an issue on Google Issue Tracker: Google Issue Tracker about mismatching IDs. Long story short:

It seems like changing authentication method from PGS V1 Google Sign In method to PGS V2 changes how Google backend is processing delivered authentication code.

Solution suggested by Google support is to update PGS library to 21.0.0 version and call RequestServerSideAccess() API with “openId” scope for an authentication code. This call generates the code with additional scope while authenticating and fills originalPlayerId (called “open ID” by Google and only if player consented to it before) field as well as provides new ID (called “PGS ID” by Google).

We are still in process of migrating to new PGS library version, therefore we still have to test if there is no other obstacles in the way, but it seems like it resolves an issue described in this topic.

6

Hi, I managed to test if I’m getting old ID as google suggested and I do but in a different way:

After exchanging server auth code for access token, I have to send a GET request: https://www.googleapis.com/oauth2/v3/tokeninfo?access_token=PASTE_ACCESS_TOKEN

This way the response for above request is populated with “sub” value, which is in fact old google ID, which I need to do the migration:

{
  "aud": "407408718192.apps.googleusercontent.com", 
  "expires_in": "3588", 
  "access_type": "offline", 
  "exp": "1757326686", 
  "azp": "407408718192.apps.googleusercontent.com", 
  "scope": "https://www.googleapis.com/auth/games openid", 
  "sub": "113792687972591949640"
}

If I could get this sub value, then I could do the migration myself using beforeAuthenticate hook.

I checked nakama code (social.go in particular) but I doubt I can access any of these classes to implement all of this myself, so the question is if there is any way for me to write custom code to achieve what I described here or it have to be done on your end?

Cheers,

Michał

7

@sesposito Hi,

Do you guys have any advice for me in this situation? I would be grateful for answer in this topic, one way or another.

8

Hi @MichalKrela,

My understanding is that the tokeninfo endpoint is only for debugging, and unsuitable for a production setting (rate-limiting, etc), so I’m not sure you can rely on it even if it’s working in your local testing.

Your thread in the Google Issue Tracker seems to indicate that using the latest client SDK should allow to request the correct scopes that shall return the OriginalPlayerId if applicable - if that’s true, then the RemapGoogleId should handle this gracefully by Nakama, have you observed otherwise?

9

Hello again @sesposito

I’m still waiting for Google support to respond to the question about OriginalPlayerId. Meanwhile, I saw that AccountGameCenter object in AuthenticateGameCenterRequest have playerId field. Is there a way to get playerId field in AccountGoogle object? This way I could implement workaround migration in BeforeAuthenticationHook.

Cheers,

Michał