Return to Answer

added 471 characters in body

edited Jul 30, 2012 at 0:17

734
5
13

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, or 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.

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, or on the receipt.

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.

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.

answered Jul 30, 2012 at 0:09

734
5
13

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, or on the receipt.

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.