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.
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.
Integrating a third-party or bespoke authentication provider with SpatialOS involves supporting two flows: an authentication flow and a login 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.
- 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).
- Your authentication server verifies the player's credentials using a third-party or custom authentication provider.
- The server must then use the SpatialOS Platform SDK to generate a
PlayerIdentityTokenusing a unique identifier for the player and your SpatialOS project's name.
- Your authentication server returns this
PlayerIdentityTokento 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
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.
- The game client requests to log in through your login server using its
- Your login server uses the SpatialOS Platform SDK to validate and decode the
- Your login server must verify that the
PlayerIdentityToken's provider and cloud match what you expect.
- 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.
- Your login server uses the Platform SDK to create a
LoginTokenfor the chosen deployment and returns this to the game client.
- The game client uses this
PlayerIdentityTokento connect to the SpatialOS deployment.
Image: The client login flow for SpatialOS in the cloud.
Updated about a year ago