Sites

Menu

Creating your own authentication server (deprecated)

If you have not already created your own authentication server, you should follow the new (alpha) guide instead of this one. The new guide describes a more flexible custom authentication system that we’ll be developing further in the future, whereas we won’t be developing this one any longer.

If you have already created your own authentication server, you should migrate to the new system.

Using your own authentication server and third-party 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.

Introduction

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 create your own authentication server. This allows you to write your own logic to validate the identity of players connecting to your deployment.

Authentication flow

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

  1. The game client requests to be authenticated through your authentication server which deals with user accounts. This step allows you to implement logic to verify the player’s identity with your chosen authentication provider.
  2. Your chosen 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 cloud 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 server 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

Creating your authentication server with SpatialOS

1. Obtain a service account

In order to use your own authentication server, you need to request a service account by raising a support request (for customers with a service agreement) or asking on our forums.

You need to request a service account even if you’ve already created one using the Platform SDK. Service accounts created using the Platform SDK are currently incompatible with creating your own authentication server.

2. Call the PlayerTokenService

When a client authenticates via your authentication server, you must call the PlayerTokenService’s CreatePlayerToken using the player’s unique identifier and the deployment’s cloud 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(
        player_identity_pb.CreatePlayerTokenRequest(
            player_identifier=player_identifier,
            project_name=project_name,
        )
    )
    

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 server, 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 Worker SDK in C#:

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);
        Environment.Exit(ErrorExitStatus);
    }
    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 server.

Search results

Was this page helpful?

Thanks for letting us know!

Thanks for your feedback

Need more help? Ask on the forums