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>`
Authentication process takes these steps:
- Player provides credentials and scopes of access;
- The system verifies if the credentials in question are valid. Each credential defines different way of verification;
- Account for the user is revealed. If there’s no account for such credential, a new one is created;
- System verifies if the account has the scopes requested;
- Access token for the account is generated;
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
However, player may have multiple credentials that prove same account.
For example, user could login using
As time goes, you may want to have multiple games hosted on the same environment.
Login service offers a special term for that purpose:
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.
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
.. toctree:: :maxdepth: 1 login/credentials
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.
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:
- 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.
- Once a Token is generated, it is signed using a private key only a Login service knows.
- 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.
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.
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:
- Open the :ref:`admin-tool`;
- Select the Login service;
- Select the section “Keys”;
Other services can use these keys to communicate with external services.
For example, a
social service may use
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.
.. toctree:: :maxdepth: 1 login/api