Skip to main content

Authentication

The server has built-in authentication so clients can only send requests and connect if they have the server key. The default server key is defaultkey but it is very important to set a unique value. This value should be embedded within client code.

Additionally, the server directly embed Universal Account (UA) system. When authentication is successful a client can create a session as a user. With UA, User account can directly submit onchain transaction to L1 in a seamless way.

The UA system aims to support console authentication for all major Social platforms, including Telegram, Google, Twitter, etc.

When authentication is successful a client can create a session as a user.

Every user account is created from one of the options used to authenticate. We call each of these options a “link” because it’s a way to access the user’s account. You can add more than one link to each account which is useful to enable users to login in multiple ways across different devices.

Authenticate​

Before you interact with the server, you must obtain a session token by authenticating with the system. The authentication system is very flexible. You could register a user with an email address, link their Facebook account, and use it to login from another device.

By default the system will create a user automatically if the identifier used to authenticate did not previously exist in the system. This pattern is shown in the device section.

For full examples on the best way to handle registering and login in each of the clients have a look at their guides.

Email​

info

UA integration is coming soon for email.

Users can be registered with an email and password. The password is hashed before it’s stored in the database server and cannot be read or “recovered” by administrators. This protects a user’s privacy.

You can choose a custom username when creating the account. To do this, set username to a custom name. If you want to only authenticate without implicitly creating a user account, set create to false.

An email address must be valid as defined by RFC-5322 and passwords must be at least 8 characters.

Social providers​

The server supports a lot of different social services with register and login. With each provider the user account will be fetched from the social service and used to setup the user. In some cases a user’s friends will also be fetched and added to their friends list.

To register or login as a user with any of the providers an OAuth, OTP or access token must be obtained from that social service.

info

UA is currently only supported for Telegram, Google, Twitter, and Facebook.

Social General flow

Note: Telegram login follows the OTP flow. To receive OTP, user need to start a chat with a Telegram bot (https://t.me/layerg_bot).

Authentication and authorization flow involving four main components:

  • Game Client
  • Universal Account (UA)
  • Game Backend
  • External Authentication Services (X, Google, Telegram)

Flow Breakdown:​

  1. User Authentication Initiation:

The Client redirects the user to an external authentication provider (X, Google, or Telegram).

After receiving the authentication code and state from the external authentication provider, redirect back to the Client.

  1. Returning Authentication Code to the Client:

After receiving the authentication code and state from the external authentication provider, redirect back to the Client.

  1. Backend Authorization Handling:

The Client then calls the BE (Backend), passing code and state to proceed with authorization.

The BE signs the request with a private key (pvk) and submits the state and code to UA for verification.

  1. Token Exchange and Access Granting:

The UA verifies the request and provides the BE with access and refresh tokens (UA access token, and refreshToken).

  1. Client Interaction with the Game Backend:

After receiving the access and refresh tokens from the UA, the Backend uses the issued tokens to call the Game BE for further UA operations. And issue another token mapped with UA one and send it to client for further game operations.

Session​

When an authentication call succeeds, the server responds with a session object. The session object contains at least the following:

  • The user ID
  • The username
  • A set of variables cached in the token
  • The creation time
  • The expiration time

Once the client obtains the session object, you can utilize LayerG’s real-time features such as multiplayer, notifications and status updates, passing stream data or real-time chat.