These are the docs for 13.3, an old version of SpatialOS. The docs for this version are frozen: we do not correct, update or republish them. 14.5 is the newest →

Integrating your own authentication provider

Using your own authentication provider is only available to select customers for testing. If you’d like access, raise a support request (for customers with a service agreement) or ask on our forums.


When an untrusted game client wants to connect to your SpatialOS deployment, it must authenticate via our services in order to establish trust and be admitted to the deployment.

This guide describes how to integrate your own authentication provider. This allows you to write your own logic to validate the identity of players connecting to your deployment.

Authentication flow

Before you integrate your own authentication provider, here’s some background on how the authentication flow will work:

  1. The game client requests to be authenticated through your authentication provider which deals with user accounts. This step allows you to implement logic to validate the player’s identity.
  2. Your authentication provider verifies the player’s credentials. You must then use the SpatialOS Public API to generate a PlayerToken using the player’s unique identifier and the deployment’s project name.
  3. The API returns a PlayerToken which can be used to log into any deployment that belongs to the supplied project.
  4. Your authentication provider returns the PlayerToken to the game client.
  5. You need to set the PlayerToken as your LoginTokenCredentials (C# / C++), so that the client can connect to your SpatialOS deployment via the locator service (C# / C++) and be considered as trusted.

BYO Auth Diagram

Integrating your authentication provider with SpatialOS

1. Obtain a service account

In order to use your own authentication provider, you need to request a service account from support.

2. Call the PlayerTokenService

When a client authenticates via your authentication provider, you must call the PlayerTokenService’s CreatePlayerToken using the player’s unique identifier and the deployment’s project name.

The player’s unique identifier is whatever you use to uniquely identify the player, such as their database ID or a GUID that’s unique to them.

  1. Look at the examples in the SpatialOS API repository to see how to generate an API client for your language.

  2. Call the SpatialOS API PlayerTokenService’s CreatePlayerToken with the player’s unique identifier and the project they should have access to. You will need the service account for this.

    stub = player_identity_pb_grpc.PlayerTokenServiceStub(APIChannel())
    create_player_token_response = stub.CreatePlayerToken(

3. Return the generated token to the client

Return the PlayerToken contained within the CreatePlayerTokenResponse to the client.

4. Connect to the deployment

Set the LocatorParameters (C# / C++)’s LoginToken to the value of the PlayerToken you obtained in the previous step. Also set the CredentialsType to LocatorCredentialsType.LoginToken (C# / C++).

When using your own authentication provider, we assume that queueing has happened on your service. This is why no queuing will take place at this point and the client will be allowed straight into the deployment.

Despite no queuing taking place, the queuing callback (C# / C++) will still get triggered.

Using the C# worker SDK:

var locatorParameters = new LocatorParameters();
locatorParameters.ProjectName = ProjectName;
locatorParameters.CredentialsType = LocatorCredentialsType.LoginToken;
locatorParameters.LoginToken.Token = identityToken;

var locator = new Locator(locatorHostname, locatorParameters);

Func<QueueStatus, bool> queueCallback = queueStatus =>
    if (!string.IsNullOrEmpty(queueStatus.Error))
        Console.Error.WriteLine("Error while queueing: " + queueStatus.Error);
    Console.WriteLine("Worker of type '" + WorkerType + "' connecting through locator: queueing.");
    return true;

using (var future = locator.ConnectAsync(deploymentId, connectionParameters, queueCallback))
    connection = future.Get();

You should now be able to authorise game clients using your own authentication provider.

Search results

Was this page helpful?

Thanks for letting us know!

Thanks for your feedback

Need more help? Ask on the forums