Authentication

Client Authentication

The primary security for authenticating valid clients connecting to the replication server is accomplished via a shared secret.

The replication server is started with the --secret option and a host-generated secret token string. Eg.: replication-server world -env prod --secret "ABCDEFG1234567" --schema "...."

When the client connects they need to provide an authority token that contains the replication server secret in the AuthToken field of the WorldData or RoomData structure. This JWT token is generated with the following properties:

  • Algorithm: HMAC SHA 256

  • Secret: the same secret as used in the --secret option to launch the replication server

  • Claims:

    • "sub": player ID string — any player identifier

    • "pid": project ID string — any project identifier

    • "type": ConnectionType as lower case string — client | simulator

The best practice for providing the client an authentication token is to provide your own authentication service which generates the token on behalf of the client and provides the token to the client for connecting to the replication server. This way, the client never knows the secret and can not spoof access to a replication server as a simulator which might have elevated permissions when using Advanced Simulator Authority.

Client as Host Authentication

In a server authoritative setup, you might want a client to act as a host instead of requiring a simulator. In this specific case, the client needs to be authenticated as a host. In this very specific case, the --room-secret option is used with a secret string when launching the replication server in world mode. This string must match the RoomSecret field in the WorldData structure when connecting to the replication server via the client. In rooms mode the room secret is defined the the Secret parameter of the /add API call and the same secret must match the RoomSecret field in RoomData.

Last updated

Was this helpful?