Improbable Icon


Deployment authentication options



Are there any other authentication options then those offered by sharing deployment links? I mean… can we use our own auth database or will there be one available from SpatialOS which we can use and put in some users so they have permanent access to our deployments?

Player persistence between sessions

Hey Flo.
steam is the main option for now ( the document is from version 8.0.0, but looking at it, it should almost certainly work for V9 ).
you could use the metadata in a worker connection to integrate playfab auth if you’d prefer?

We’re making it easier to share things for sure: I’m thinking of a combo: tag & perma link. But that won’t make it in for v10.

Any other suggestions other than the custom auth database?


Hey Cal,

steam is the main option for now ( the document is from version 8.0.0, but looking at it, it should almost certainly work for V9 ).

Yep, but requires greenlight, not an option in an early stage :slight_smile:

What does the steam integration exactly do?

Configuration.Networking.SteamToken = SteamManager.GetSteamTicketString();

Is there something happening at the backend? Some kind of verification that this is a valid steam ticket?


With this it should be possible that clients connect without being authenticated. Is the steam integration a real authentication or just the usage of steam usernames? :stuck_out_tongue:

you could use the metadata in a worker connection to integrate playfab auth if you’d prefer?

What exactly can i do with this? The docs say:

You’ll be able to edit the configuration from the Bootstrap script (see above) in the Unity Editor. For more information, see the in-code documentation for WorkerConfigurationData.

But the in-code documentation is little helpfull. There is a string “LoginToken” and another one “SteamToken”. What can i do with them and how does the authentication works?

  • With a link the user is authenticated against google/github/microsoft. Is there a relation to the assembly or deployment?
  • Can i use a custom auth somehow, you mentioned playfab, but how to integrate it?
  • Can i share the client without using the share link and do authentication completely myself? (Client looks up running deployments, user enters credentials in client and backend does the auth against something?)


Hey @daschatten,

Will try to clarify some of this here.

TL;DR: we have two supported authentication mechanisms - our own (via the Share links / Launcher) and Steam.

Our Steam integration does indeed require a Steam project (either via Greenlight or other means :stuck_out_tongue:). The flow works roughly as follows:

  • Player launches a game via Steam (executes a normal UnityClient).
  • The UnityClient gets a Steam auth token for the player via the Steam Unity integration and passes it to SpatialOS.
  • SpatialOS validates the token with Steam to ensure that user has access to that game.

Note: this requires us to have pre-existing knowledge of your Steam AppID and WebAPI keys.

Share / Launcher
You can authenticate clients launched via the Share links with our own auth system. The auth tokens have a fairly short expiry though, so the links aren’t valid for long (6 hours atm).

PlayFab authentication is on the roadmap for the future, but is not yet available. Similarly, you cannot use provide a custom auth implementation at the moment (although you can certainly add another layer on top if you wanted to, similar to PlayFab!).

Any further questions feel free to give me a shout :slight_smile:


Any updates on this? We would need at least share links with longer validity soon, maybe 2 weeks?


Hey @daschatten!

Thanks for following up.

We are currently working on this improved sharing workflow to enable sharing a deployment with just 1 URL (instead of the 5/20/50 ones + having to keep track of which one has been redeemed).

We are targeting a release of this in the next 2 weeks, I will keep you posted as soon as I have a specific date.


It would be awesome if SpatialOS offered this feature built-in. You would think that player authentication would be a common use-case. Every MMO I have ever played uses it.


Hey @VectorXStudios,

Offering a first class auth integration isn’t on our roadmap. You’re correct that every MMO needs authentication, but so far we’ve only been asked for integrations like Steam and Playfab: as third party providers they offer a fantastic suite of tools for managing distribution, metrics and refunds etc.

Is there a specific use case you’re thinking of in terms of distribution or auth?



Somehow I missed this topic … but to add:

I have integrated Playfab as an authentication provider (and planning on using more of its features to be able to link another app to my game). I used the following workflow:

  1. I added the Playfab SDK
  2. I split the Bootstrap script into a Client and Worker Bootstrap
  3. In the Client bootstrap I do not automatically connect to Spatial upon starting
  4. Instead I first authenticate with Playfab (currently using the device identifier so I don’t need to create a user management front yet)
  5. As soon as the event triggers that indicates that login has succeeded I
    5.1. Populate the Spatial metadata with the Playfab PlayerId (this is my canonical playerId since it never changes)
    5.2. Connect to SpatialOS

This workflow enables me to do several things but most importantly I have a persistent canonical player Id and I can delete player entities as soon as they quit the game, I can associate other entities with my player object based on its canonical player id, and I can defer connecting to Spatial until a sign in was successful.

I hope this helps anyone, and if you would like more information I’d be happy to provide it


Hey @daschatten

This has just been released - thanks for your patience!


Well, it gets into the whole persistent player data area. This is also something I was hoping SpatialOS would offer. I can integrate with Google Firebase or something but having my data “all over the place,” seems to invite problems.

For example, World of Warcraft. I have several characters that have inventories, achievements, skills, etc. When I connect, the player data is loaded into the world for my avatar. For SpatialOS, do I need to do all of the persistency via a separate system? What about changes? If the player spends gold or gains experience points, do I need to sync between the systems?

Problems can arise if I had to do a rollback. In systems I have worked with, when you rollback the world, it also rolls back the players. If the systems are not connected, this seems problematic? For example, Player A hands Player B gold. Something goes wrong and they never get the gold but it disappears from both players inventory. How do you reconcile the issue if player data is stored and managed somewhere else?

I know there are answers to these as you can always roll-your-own. It would be appealing for it all to be in one place is my basic statement. I thought about even having a “place” in the world where players data was stored via entities that never died nor could be found but that seems quite “hackey”.



Hey @VectorXStudios

Some great discussion topics you’ve raised!

The best case study currently would be Worlds Adrift for which the awesome @sami has provided me with some information. The main issues that arise with persistent game data are:

  1. How do you store the data?
  2. How do you do reliable transactions?

Reliable transactions are much easier with an external database (which is what Worlds Adrift uses) where the external database will likely have its own guarantees. Storing critical data in the player entities themselves doesn’t make too much sense unless the simulation is truly persistent and leaves your player entities in the world even after logout. The reason for this is that you might want to take a snapshot, take the server down (e.g. for game maintenance) and then restart. When you restart the clients connected from the last snapshot will no longer be connected so you’d have to remove their player entities from the snapshot and place in some kind of external database so it’s ready for when they log in again anyway. This leads onto your suggestion of a persistent ‘database entity’. This would work but would cause some load on the simulation at all times, even when the players whose data is being stored aren’t logged in.

The issue of handing gold between Players A & B seems more like a question on the functionality of Commands which is a really interesting and important topic but probably best saved for another thread. On a basic level I imagine there are multiple ways you verify transactions by exposing some data on each player as a component or in a remote database. This is on top of the fact that Commands have the guarantee of having definitely succeeded on returning successful.

The solution to rolling back will likely depend on your application. If you have a game where a user might have made some real-world transaction then you would want this stored in the database and not rolled back. You could also put timestamps on transactions and rollbacks could be done more selectively.

I’ll try and get someone from our Product team to add to the discussion more!

Hope this has been informative to some extent at least.



Can workers make outbound HTTP(S) requests? For the database to not be tied to the SpatialOS world, the worker will have to make an external call to validate the user can indeed play the game? Or is there some other way to do this?

What I’m struggling with is how to handle validation from client to external system to SpatialOS. I know how to write an authentication system. But getting it to sync with SpatialOS is where I’m confused.


State saving - How with SpatialOS?

Hey @VectorXStudios,

I’ll try to pitch in with some details to clear-up some of the apparent mis-understandings that you have (don’t get me wrong, this just means that it’s we who need to improve our documentation, communication, etc.).

Workers can connect to external HTTP(S) endpoints. One of the usages for that is for example to an external third-party database service like Firebase. This is however not how you are going to do authentication because that is not done by the workers (game clients are workers themselves).

Authentication is done before people actually connect to your deployment(s) via the same type of back-end service that allows you to log-in to the deployment console, etc. I’ve described this in some detail in the first halve of my reply to another user. So long story short: the authentication for people will need to be done via a service like Steam, Playfab or others that we have not integrated yet. It might be interesting at some point to be able to integrate your own custom service but that’s just my own speculation and I cannot guarantee anything there, be it on how that would work or when it would potentially be done.

Hope that this helps somewhat!

PS: I’m still writing a more elaborate answer to your other question about data in your new dedicated topic :wink: .


I understand; it makes sense for the initial authentication. Given that, how do you ensure the client is authenticated to call the worker? If the worker is not sync’ed with the external authentication system, unauthorized rogue clients can technically connect right?

I do not want to be in the position of trusting the client to tell workers it is legit. Make sense?

Most flows I am used to this process:

  1. Client calls auth system with credentials
  2. Auth system returns a token if the client is authenticated
  3. Client passes token to gaming server
  4. Gaming server checks to make sure token is valid and confirms client requests

If #2 and #4 are not in sync, how does it work in SpatialOS? I asked about the HTTP(s) call because I was thinking the worker could make a API call to the auth system and see if the token was valid before spawning the player.


Actually you’re anticipating a problem that does not really exist. :slight_smile:

The authentication flow currently goes as follows:

  1. Client contacts auth system with the credentials and the name of the deployment it wants to join
  2. Auth system checks credentials.
  3. Auth system contacts the deployment and requests to spin-up an end-point to which the new client can connect.
  4. Deployment sends back the details (IP & port) of the new end-point to the auth system which forwards them to the client.
  5. Client connects to the given end-point.

After 5.) you don’t need any further credentials or authentication tokens as the client is the only one on that connection. And if I may insist on one point: your client is a worker itself. Once connected it is not different from any server-side worker as far as SpatialOS is concerned: the client may send commands to server-side workers and they may send commands to the client while both are receiving and sending component updates from the core of the platform. The client only only needs authentication when joining the deployment.

As a developer you don’t even have to care about the internals here as the whole process is done via a single API call in Unity. In C++, in C# or Java this is also via a single call in the worker::Locator class.

Note that the above flow is only valid for clients (e.g game clients, etc.). Server workers have a different flow in non-Unity SDKs which is also wrapped in a single API call in the worker::Connection class. Server workers do not need authentication as the deployments fully controls their life-cycle.

State saving - How with SpatialOS?

Ah cool… Great to know. Is there a ClientID I can use that always represents the player regardless of the connection time or the worker involved? Basically a hard-key I can use for off-line storage on a 3rd party system (such as Googles Firebase).


That ClientID would for example be the user ID on the third-party authentication platform that you use (Steam for example). That information will get passed in anyway to your client in order to connect to the deployment. So you can use the same ID then to query Firebase or any other external database that you use for the user’s data.

Does that sounds like a workable solution to you?


@VectorXStudios you can take a look at to see how I did the Playfab integration. It also shows how to inject the PlayFab player id using Meta-data


Thanks @dvanamst and @draconigra,

Question… how do you keep from the client telling the server their ID? A “man-in-the-middle” hacker could use this to pretend to be someone they are not if you are relying on the client to be authoritative in this regard.