The largest conceptual change between setting up an authentication server with the Platform SDK and the deprecated approach to setting up an authentication server without the Platform SDK is the separation of
PlayerTokens into a
PlayerIdentityToken and a
This separation reflects the differences between the authentication of players and the assigning of players to deployments:
- Players should only need to authenticate with your game (for example, prove they have a valid username and password) once per session even if this session involves connecting to multiple different deployments. As a result
- are not tied to a specific deployment.
- are longer-lived than
LoginTokens (by default they are valid for 24 hours).
- Permission to log into a deployment should only last long enough for the player to establish their connection and should only allow connection to a specific deployment. As a result
- are short-lived (by default, they are valid for only 15 minutes).
- are valid only for a specific deployment ID.
When migrating your authentication server to the new authentication system there are two options:
- A simple migration which moves your game client and server to use the new authentication API methods but otherwise requires minimal changes to how your game client and server interact with each other.
- A full migration which additionally changes how your game client and server work to benefit from the separation of authentication (obtaining a
PlayerIdentityToken) and requesting to join a deployment (obtaining a
You can find more details about each of these options below.
The simplest migration option (requiring minimal changes to your game client) involves modifying your authentication server to generate and return both a
LoginToken upon each authentication request from your game client.
For your authentication provider, this requires making two calls to the Platform SDK (specifically, the
CreateLoginToken methods) rather than the single
CreatePlayerToken method. You should ensure that the service account you are using has the correct permissions to call these methods as described here.
For your game client this only requires modifying your authentication code to expect both of these tokens in the response from your server, and changing your Worker SDK
LocatorParameters to the values described here.
This simple migration achieves many of the benefits of the new authentication flow:
- You gain fine-grained control over which deployments in your project a player can connect to.
- In the future, the trusted player identifier field in the
PlayerIdentityTokenwill be accessible in the Runtime allowing your server logic to link a player within the deployment to their identity outside the deployment.
To fully migrate to the new authentication system, your game client needs to have separate calls to your authentication provider for authentication and for logging in to a deployment. This process is sufficiently different from the one described above that it is preferable to follow the new guide in full rather than attempt to adapt your existing solution.
Although full migration has a larger development cost than the simple option, it comes with the benefits that:
- Players can authenticate with their client starts and then log into and move between deployments without having to re-authenticate each time.
- By running separate authentication and login servers you can horizontally scale these by different amounts. For example, you can run more instances of your login server because it runs intensive matchmaking logic as opposed to your authentication server which performs much less computation.
Updated about a year ago
See the guide to the development authentication flow.
|Authentication during game development (alpha)|