🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

Android background authentication

Started by
1 comment, last by hplus0603 8 years, 10 months ago

Hi,

I am working on a multiplayer card game and thinking about how I handle the login.

The connection to my backend happens automatically.

When creating a new account, I wanted to create a token and send it to the client.

I have taken the timestamp and these hashed with the UUID in SHA.

But that does not seem the best solution to me.

In Android, I can use the account manager to generate a token, but then a message prompt.

Clash of Clans uses a system to detect clients without login or message prompt and

use facebook or google+ just for transfering the account.

What is the best practice to detect my clients without an active login or message promp ?

Advertisement

Depends on the features and security you need from your login system.

To totally avoid user interaction, in a simple scenario you could:

  1. Read the device unique ID, or generate and cache a random UUID.
  2. Send that to your server.
  3. Server identifies the client and ties them to an account for identity and data segregation. This may allow you to later add account recovery on new devices, perhaps.
  4. Server replies with a session token.

If you want to avoid having a server-side session store you could return something like a JSON Web Token. This is generally better than a SHA hash because you can use the token contents (account ID, time of login) but still verify the token crypto hash to check it's a real token issued by your server.

There are a bunch of other ways you could try, but these are fairly simple and popular.

Hope this helps!

Source: I'm one of the engineers at Heroic Labs, we've seen a lot. happy.png

I'm assuming you're currently writing a mobile game client.

There are three drawbacks to using an "automatic" login.
1. Anyone who can sniff that network traffic (a Stinger, a WiFi access point, etc) can impostor the player. Using HTTPS makes that a harder attack, but not impossible.
2. If the player wants to play from another device (console, web browser, PC, etc) then there's no way of tying the player to the account.
3. If the player loses his/her phone, he loses his/her account.

All of these are solvable. Using the Google Play API on Android and the Game Center on iOS is probably the simplest way of doing it.

Sending a unique hard-to-guess token to the device, and storing that on the device, is not bad; that's very similar to a "session cookie" that a web browser will use to track logged-in state. Making this cookie only valid for a certain time is a common-sense security precaution, but if you don't have a name/password/email/phone-number of some sort for the account, there's again no way to recover it.

So, the question is entirely what you want your user experience to be.
enum Bool { True, False, FileNotFound };

This topic is closed to new replies.

Advertisement