Sign In Register

How can we help you today?

Start a new topic

Frictionless authentication

So I usually adhere to the mindset of frictionless auth when dealing with mobile apps/games - that is, new users are automatically registered with whatever backend I'm using by just their unique device identifier. Then, after being set up that way and given access to the app, they may later optionally decide to connect this new anonymous account with a custom account (username and password) or social account (like facebook).

However when I was going through the GameSparks docs, I saw the following:

Please be aware that this persistence of device authentication might cause problems if players are either sharing a device or if a player sells a device after authentication. Even if the seller wipes all data off the device before selling it, if the buyer installs GameSparks again, the device may be recognized as previously authenticated, depending on the specific OS implementation, and could be linked to the first player as owner of the device when it was first authenticated.


I never thought about this potential issue before. If a new user comes across a device that previously authenticated with one of my games before using the anonymous device auth method that most BaaS' have, how do I recognize this and register this device as 'new' again? Has anyone thought of a solution to this?

I'm fairly new to GameSparks but I'm sure there's some sort of "Delete this account" API call we can make from the client. But I'm thinking the only way to do that is to first log in this new user into the previous device owner's account, then present them with a "Is this not you?" prompt. Something they could very well dismiss if they choose to just keep the previous device owner's data.

Unless you have a very popular game I doubt you'd experience this very often, if at all. More than likely a rare edge case. But it would be nice to have something in place to handle this cleanly without exposing the previous owner's account data first, if anyone has any ideas.

Related questions:

1) Do we need to explicitly store a received authToken after authenticating a user, or does the SDK automatically handle that?

2) Roughly how long do the authTokens last for? Is it a static amount of time ('this token is only good for 1 week of authentications'), or is it dynamic ('as long as this user continues to return to the app once a week, this token won't expire')? Can we explicitly set how long we'd like for it to last for particular apps?

3) If it is handled by the SDK automatically, is there a method we can call to determine if this device/user is still authenticated so that we don't try to re-auth them via a sign-in window when it's unnecessary?

4) If such a method like 3 does exist, and we get a response back indicating that the authToken has expired, is there a way to query the SDK to see what method of authentication did the user last use? For example, say they last authenticated anonymously by device, but after inactivity their authToken expired. How do we query that so we re-authenticate them again by device, instead of erroneously trying to prompt them for a username and password for something like RegistrationRequest?

5) Does the SDK handle passwords sent along with calls like RegistrationRequest? That is, is it using HTTPS and encrypting data sent, or do we have to handle encryption and such client side before using the API?

6) For the few pages in the docs I did see about device authentication, one page shows authenticating via device without needing to pass anything in (, while another says deviceID and deviceOS are actually required ( Which of these pages is correct?

Answers to these or pointing to documentation that answers them would be helpful. I looked around the docs myself but a lot of it is outdated and there's surprisingly very little about Authentication.

7) I understand SetDurable can be set on requests to queue them up in case a user loses connectivity for a period of time. If I wanted to implement an offline mode for gameplay, would SetDurable on all requests while the user is offline be a feasible solution? How many requests can we queue up at a time? Will the queuing of many requests during a long offline stint by the user lead to the client exceeding the System Limits set by GameSparks?

Login to post a comment