Create an authentication server - overview

If you've already created your own authentication server using the deprecated Authentication server without the Platform SDK guide, see the migration guide before using this guide.

When a game client wants to connect to your SpatialOS deployment, it is initially untrusted and must authenticate via SpatialOS services in order to be admitted to the deployment.

This page and Set up an authentication server with the platform SDK describes how to create your own authentication server which integrates your chosen authentication method/provider with the SpatialOS authentication service. This allows you to write your own logic to validate the identity of players and control which deployments they can connect to.

When to set up an authentication server

Until you have completed an implementation of your authentication server, your game client can use of the Improbable development authentication services described here. Once you have set up your own authentication server, you can easily migrate your game client to instead authenticate with your own server.

Overview

Integrating a third-party or bespoke authentication provider with SpatialOS involves supporting two flows: an authentication flow and a login flow.

Authentication flow

One of the first things a game client does when it starts is go through the authentication flow. This verifies that the player is permitted to play the game, for example, by checking that the player has an account.

The steps below outline how an authentication server should interact with your game client. You need to implement your authentication server and game client to follow these general steps.

  1. The game client requests to be authenticated through your authentication server. This request should contain enough information for you to be able to validate their identity (for example a username and password).
  2. Your authentication server verifies the player's credentials using a third-party or custom authentication provider.
  3. The server must then use the SpatialOS Platform SDK to generate a PlayerIdentityToken using a unique identifier for the player and your SpatialOS project's name.
  4. Your authentication server returns this PlayerIdentityToken to the game client. The game client can now use this token to prove its identity within SpatialOS until the token expires (by default a token is valid for 24 hours).

Image: The client authentication flow with SpatialOS in the cloud

Login flow

Once a game client has a PlayerIdentityToken it can go through the login flow. This where your login server decides which deployment a player should log in to, and creates a LoginToken that allows the player to log into that specific deployment.

The steps below outline how a login server should interact with your game client. You need to implement your login server and game client to follow these general steps.

  1. The game client requests to log in through your login server using its PlayerIdentityToken.
  2. Your login server uses the SpatialOS Platform SDK to validate and decode the PlayerIdentityToken.
  3. Your login server must verify that the PlayerIdentityToken's provider and cloud match what you expect.
  4. Your login server decides which deployment the player should join. For example, you can implement a matchmaking system, choose a deployment based on the player's location, or present a list of deployments for the player to choose from themselves.
  5. Your login server uses the Platform SDK to create a LoginToken for the chosen deployment and returns this to the game client.
  6. The game client uses this LoginToken and its PlayerIdentityToken to connect to the SpatialOS deployment.

Image: The client login flow for SpatialOS in the cloud.

Updated about a year ago



Create an authentication server - overview


Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.