What methods are there for providing means of authentification for multiplayer?

A few thoughts:

  • I don't want to be restricted to a single publishing platform such as Steam.
  • Something like OpenID would be great, but OpenID itself seems to be limited to the world wide web.
  • It shouldn't be anything cryptic, so if you know the email or the user name of your friend you should be able to find him with that.
  • People shouldn't be required to create a additional account just for this one game.
  • OCS could be used for something like this but afaik it's not supported by any big vendor. So it would be somewhat useless.
  • Things like querying what the players friends are are optional.
  • \$\begingroup\$ if the authentication is tied to them purchasing the game then managing it yourself is a good idea. Minecraft has it's own implementation which is essentially a boot loader of the game allows them to provide updates to the game and authentication for its use. \$\endgroup\$ Jul 27 '12 at 15:47
  • 3
    \$\begingroup\$ When you say "People should be required", did you really mean the opposite? \$\endgroup\$
    – Kylotan
    Jul 27 '12 at 19:11
  • \$\begingroup\$ oooooooops, yes. \$\endgroup\$
    – API-Beast
    Jul 27 '12 at 19:14
  • \$\begingroup\$ Why exactly are Steam and Windows LIVE no-gos? Steam runs under Windows and Mac OS, and will be coming to Linux in the near future, so doesn't restrict things based on platform. Is there another reason? \$\endgroup\$ Jul 29 '12 at 5:29
  • \$\begingroup\$ Clarified that, I simply don't want to be restricted to a single publishing platform. \$\endgroup\$
    – API-Beast
    Jul 29 '12 at 7:27

If you can embed a browser in some form, one that supports cookies or similar, then the likes of OpenID, OAuth, Facebook Connect, etc., are open to you.

If not, then it's a bit more complicated. Generally you will have to maintain your own server and store accounts on there, and authenticate players by requiring them to enter the password for the account.

Ultimately this type of authentication just authenticates that you either know the password or have access to a certain email address associated with the account. As such, you can authenticate someone by sending them a random number to their email account and requiring them to enter the random number into your app. The benefit is that you don't have to store anything except which random numbers you sent to which addresses - the downside is that it's a hassle for users compared to even a password system.

Another type of authentication is to authenticate that it's the same machine playing the game as before. Browser cookies basically work this way - the server tells the browser to write a small file to disk and send it with every request to that site in future, so that the browser knows it's the same user each time. You can do something similar by giving each player a cookie which the app saves on their machine and sends to your server each time they log in. The cookie needs to be encrypted to ensure that people can't generate fake cookies, and you need to be careful that it doesn't get deleted or the account is effectively lost.

In general, authentication is a hard problem, which is why most places still resort to a simple username/email and password system.

  • \$\begingroup\$ I quite like the idea with the file. If the player supplies a e-mail address "losing" the account should be avoidable. \$\endgroup\$
    – API-Beast
    Jul 27 '12 at 19:41
  • \$\begingroup\$ You might want to add Mutual Authentication SSL (along the lines of the 'file' route). It's how I am doing the authentication for the middle-ware network layer that I am writing for my friends' game. It obsoletes the need for online connectivity - obviously the file can be copied, but you can't beat piracy (and the same thumbprint can't be used on a single server in e.g. a LAN). \$\endgroup\$ Jul 30 '12 at 14:57
  • \$\begingroup\$ Probably best if you post your own answer about it, because I don't know much about it and a quick Google search only turns up quite complex sources. I'm not sure how it would remove the need to be connected though since you can't exchange certificates with a site you can't reach. \$\endgroup\$
    – Kylotan
    Jul 30 '12 at 16:29
  1. If you don't want to require the player to create an account, you must support an account they already have.
  2. There won't be a single system where all players already have an account.

Therefore you must support multiple systems. Look at what Stack Overflow does. They allow logging in with one of 12 existing accounts, or you can create an account on their site directly.

One of the developers I worked with decided that on their own site they'd have you log in with their own account, but if you come from Kongregate, then you can use your existing Kongregate account, and if you come from Steam, then you can use your existing Steam account. That way players aren't forced to create another account, but if they're coming from a place that already has one, then they can use it. Otherwise, they do have to create a new account.

I think if you want to satisfy all of your requirements you have to allow multiple types of login.


You can easily use OpenID, there are a great number of libraries available. However users might have to create an account there just for your application. Integrating facebook/google/yahoo authentication is also easy, but I find requiring an account in a service I don't use/like, just to use an application extremely obnoxious.

If you want to implement something yourself it is as easy as distributing a key with your application. Since that key is unique, random and only known by one user you can use it to log the user in, optionally requiring a password. You should store the key so that it is recoverable, like in the distributors cloud, on the receipt, or have the option of mailing it to the user.

You can also require a machine-based authentication (like steam) where you generate a unique key from the machine your app is running on, register it together with the application-key to your server and mail the user a confirmation key he has to type into his app once. The machine can now safely authenticate without requiring a password from the user. The process has to be repeated every time the hardware changes though.

Now that the user is logged in, you can store additional details about him, that you get from the platform he is using (steam, windows live, ...) or a contact form in your application, or data from the receipt, etc.

If you give the users the ability to name themselves you should make the username unique, to allow search and friend requests. If you don't want real uniqueness, you can go the blizzard way and use GenericUser#1234.

  • \$\begingroup\$ The libraries in that link are for web servers, not for desktop applications. It appears not to be possible to use those technologies without implementing a browser itself. \$\endgroup\$
    – API-Beast
    Jul 30 '12 at 23:02
  • \$\begingroup\$ @Mr. Beast: The second library is for native C#. It contains asp.net controls, but you are not required to use them. There are libraries for most other major languages too and they do not require a web browser. They will obviously need web access to contact the servers though. \$\endgroup\$
    – Darcara
    Jul 30 '12 at 23:19

Chances are you will need to roll your own if you don't like the idea of embedding a small webbrowser directly in the game or opening up one. You will need to setup your own server (but you would probably need to do that anyway).

For rolling your own have a look at how web pages normally handle authentication.

Your not going to get away with having them not create an account (otherwise what are they logging into), you can however make it very quick and painless. If there is no account with that username, ask if they want to register it and then just do it without asking a bunch of things like emails and so on (Reddit does that). If you want to ensure they can recover their password then make the email optional.

Your not going to find a 3rd party login system that won't require to visit to their stuff to authorize things. Since the alternative would require the username/password to be entered in every single 3rd party program, it would be trivial for a malicious developer to capture that information (of course that's possible anyway since they could fake something like a Google login prompt).

A few important key points if you setup your own: * Firstly make sure everything is done over encryption (SSL/TLS). This will stop man in the middle attacks. You will need to use a signed certificate. Either use the main certificate authorities (StartSSL does them for free). Alternatively if you don't want to bother with the certificate authorities you can self sign and ship the public side of your certificate as part of the game executable. If you don't use a cert then someone can do things like setting up a fake DNS on large lans and steal logins by acting as a proxy between the player and your servers.

  • Make sure passwords are encrypted hashes in the database, not in some plain text form. If you don't do this you risk the chance of getting hacked and having everyones passwords stolen. Even if you force everyone to reset their passwords there is a good chance many (most) of them are stupid enough to have used password for multiple places. For example their email that is often used to send them new passwords for just about every other account they login with. This would be a massive PR nightmare.

  • Use randomly generated salt, unique for each login stored with the account. This stops people from reversing the hashes by using precomputed databases.

  • Use multiple rounds of encryption. Even with salt it's possible to break a few accounts in a time frame.

  • Try not to build as much of this as possible, chances are you will mess it up in a big way. Look at bcrypt/scrypt for decent password hashing functions that include multiple rounds designed to scale difficulty with modern hardware. If possible find a complete password storage library that has been prewritten for your language/platform. Things that have more use have more testing and are often designed by a team of people much smarter than you are. Assume your own programming is horrible and will get hacked, then program in a way to ensure if that does happen it's not a major disaster. You can't afford to cut corners here just because something is hard, or you think that a particular problem is unlikely to occur, or because your user base isn't going to be that big and you can fix it later if it grows.

  • Make sure your random numbers are generated in a cryptographically secure way. The default random function in your programming language isn't likely to be.

  • Generate a random token that is sent to the player, that authenticates them. If you wan't to offer a 'remember password' function it might be better to just store the token rather than the password. That way if someone has access to the players computer they can't steal their password just the token that can be reset. You will need to keep track of all active tokens and there may be multiple per player. Time out the tokens eventually.

It's a good idea to make a very minimal login server that runs on a separate server from your other components. Since this is where all the security is if your main game server/website is hacked in your login database won't be compromised. Make sure you log everything.

If you don't want your own host, you can look at Google App Engine and similar solutions. It's even free for small usage cases.

It might be worth looking at how XMPP handles authentication. Of course the whole standard is somewhat over engineered for a whole game. But it does do chat as well. XMPP itself could serve as a authentication system but it would be kind of a hacky use of it. I'm not sure if Google would allow that kind of use with GTalk since they probably don't like 3rd party programs asking for password. You could operate your own XMPP server and get chat, authentication and encryption, but you would need a XMPP client built into your game.

OAuth isn't too bad, it only would require the user to use the webinterface one time to authorize the program to be linked and it works with Google/Facebook and probably quite a few others and it does mean you no longer have to bother with running your own server.

BrowserID is another new alternative. But it's also a browser based system.

  • \$\begingroup\$ Wow, isn't that a bit much security? I mean it's just about a master server for a game, the worst thing you can do is taking the identity of someone else and play pranks with that, and the most valuable data on the server would be the e-mail-address. \$\endgroup\$
    – API-Beast
    Jul 30 '12 at 22:49
  • 1
    \$\begingroup\$ @Mr.Beast: What they can do in the game is irrelevance. If a hacker can obtain players password+email from a compromised database. They can then use the password on email (which in most cases will work as people often use the same pass for everything). They can then search the email for more passwords and other accounts. Credit card details. Information for identity theft and so on. Use the accounts to send out spam, viruses and so on. Setup the accounts to automatically forward all received emails to another address so even if the password is changed they can keep getting information. \$\endgroup\$ Jul 31 '12 at 3:50
  • \$\begingroup\$ In any case doing most of that isn't hard. Most of the time you can find an off the shelf library to do it (this is better than doing it yourself). You just need to be sure you are doing it. \$\endgroup\$ Jul 31 '12 at 3:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.