Skip to content
Permalink
Branch: master
Find file Copy path
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
171 lines (119 sloc) 5.06 KB

Login Service

At the very moment of game experience, it is critical to ensure user’s progress is not lost, or even worse, stolen.

This service allows players to prove themselves, in a bunch of different ways.

.. seealso::
   :anthill-service-source:`Source Code <login>`

Login process

Authentication process takes these steps:

  1. Player provides credentials and scopes of access;
  2. The system verifies if the credentials in question are valid. Each credential defines different way of verification;
  3. Account for the user is revealed. If there’s no account for such credential, a new one is created;
  4. System verifies if the account has the scopes requested;
  5. Access token for the account is generated;

Player Account

Login service have simple account system: each player have unique personal account number attached to him. If the user is logged in for a first time, a new account is created automatically.

The main purpose of Login Service is to verify that player X owns account N.

images/login_accounts.png

Note

However, player may have multiple credentials that prove same account. For example, user could login using google or facebook, but both of them will lead to the same account.

Gamespace

As time goes, you may want to have multiple games hosted on the same environment.

Login service offers a special term for that purpose: gamespace. It allows to split the game experience from other games, like a namespace keyword in various programming languages. Yet they run on the same software server-side.

For example, if you would like to divide mobile player from PC once, you may put them in different gamespaces. But if you want to combine them, put them under the same gamespace.

Credentials

Login Service allows to :ref:`authenticate` a player in many different ways.

Say a bowling club provides a free game for clients who’s birthday today. To prove the day of birth, a client may profide a passport, or driver’s license, or even a birth certificate.

These are different kinds of documents, but they prove same identity.

That’s where the credential system kick in: player may have multiple credentials that prove same account. For example, user could login using google or facebook, but both of them will lead to the same account.

.. toctree::
   :maxdepth: 1

   login/credentials

Hint

To authenticate with corresponding credential type, pass the appropriate credential type as credential field during authentication.

Scopes of Access

At some point, there should be a way to ensure the player A has the right to do something, but player B has not.

For example, administrative account can move mountains, while simple guest account can do only simple operations.

Access Scopes are used to ensure that. At authentication, player sends the complete list of access scopes he needs, then the system makes sure he owns them.

Access token

Instead of checking if user have a certain access right for each request, login service uses Json Web Tokens to ensure user’s identity.

Basically, it’s a JSON object with all information about the player:

  • Token’s UUID itself
  • Player’s account ID
  • Player’s credential
  • Scopes of Access
  • Issue and Expiration Date

So each service during request process does not have to lookup if the player have the access rights, but can lookup this object instead.

In order to validate if the Token was actually generated by Login service, a public-key cryptography method is used:

  1. An RSA public/private key pair is generated on Login service on service setup. The private key is kept secure with paraphrase protection on it. Public key, instead, is copied for each service.
  2. Once a Token is generated, it is signed using a private key only a Login service knows.
  3. Other services verify it using public key.

In addition, there’s a system that ensures the only one token is valid for account at the same time, to avoid using same account from multiple devices.

Warning

Treat access tokens as raw string at all times. The format of an access token can change at any time, so the game should make no attempt to parse it.

Anthill Keys

Login service allows to securely store private keys for external social services. For example,

  • A Google’s OAuth Secret
  • Facebook App ID and Secret
  • Steam app_id and WebAPI key

To manage these keys:

  1. Open the :ref:`admin-tool`;
  2. Select the Login service;
  3. Select the section “Keys”;

Other services can use these keys to communicate with external services. For example, a social service may use google key to fetch player’s friend list.

Please note that there can only be one key with same name, for a gamespace. If you would like to have a few keys with same name, put a new one under different gamespace.

REST API

.. toctree::
   :maxdepth: 1

   login/api
You can’t perform that action at this time.