Authentication for Game Developers

Pley has its authentication built in two parts; the in-game authentication and the headless destination authentication. This article discusses the in-game auth. It is split up into two so that games can be launched on any website, with any authentication systems, and always work. Additionally, game developers can focus on the game client.

This setup allows games to launch on their own websites, and then also be launched on third-party channels such as Discord or CrazyGames. Players can play on all of these places, and Pley can automatically handle account linking across the different places where the game is played. This way it is always your one unified game, at no extra effort for you.

Terminology

Term	Meaning
Pley Game User ID	This is a unique, permanent ID that identifies the user currently playing your game. Should be saved to the players in the game's database.
Session Token	This is a unique token generated every time a user starts a new session for your game (similar to a session ID). This token is only valid for a limited time (~30 minutes). The Session Token is used to do Game backend -> Pley HTTP Server user validation.

Authentication in-game with server verification

Article: How-to implement Pley's authentication and how to fetch/send Pley session tokens.

To authenticate safely no matter where your game is running, your game should authenticate player sessions with session tokens.

Game Client requests a session token from the Pley SDK.
Game backend verifies that session token with Pley, receiving a player identifier in return.
Game backend authenticates the session serverside, saving the Pley Game User ID to the user.
If a user exists with that ID, the game starts with that progress. If none exist, the game creates a new progress.

Since the Pley Game User ID is unique to each player and does not change, it can be used as a source of truth. By saving that ID to a player, authentication will work no matter where the game runs.

Authentication for Games with no server verification

Article: How to implement Client-side Authentication & Payments

Not all games have servers that can do HTTP cURL requests or authenticate a client. For games with only a database and some server functions, the game logic is very local.

For locally operated games, Pley provides a simple way of determining which user is playing the game. However, this method is much less secure and is not recommended.

The Game Client requests the Pley Game User ID from the Pley SDK.
The Game Client uses that pleyGameUserID as a device ID or player ID to authenticate with the backend.
If a user exists with that ID, the game starts with that progress. If none exist, the game creates a new progress.

Since the Pley Game User ID is unique to each player and does not change, it can be used as a source of truth. By saving that ID to a player, authentication will work no matter where the game runs.

In this case, the Game Client is not authenticated by the Game Server (which is much less reliable and secure). The web game client provides the PleyGameUserID to the server, which is used to get the right game progress for the user.

Authentication for Games launching on a Headless Destination

Article: [What is a Headless Destination?](doc:Launching a Headless Destination)

If your game will be launched on a gaming destination built by you, a partner, or a publisher some additional steps is required.

The new web gaming destination will have a login system on the website. This login system's server will need to know which game users are connected to which destination accounts, including the Pley Game User ID if there is one.
To gain cross-platform account linking (which is HIGHLY recommended), there need to exist a way for mobile-only players to either login or link their mobile progress with this account system. This has nothing to do with Pley.

Without Pley (Mobile)

Most of this implementation has nothing to do with Pley. This implementation depends on the login system you are integrating with. The game server needs to:

Allow players to either login within the mobile game, or link their game progress (such as with a code)
Provide to the Web Gaming Destination Login Server which Game Progress/user is connected to which account.

This would work similarly to having accounts in-game using Apple, Facebook, or Google to carry progress across mobile devices. If a player does this account linking, their progress should be linked to anywhere else they login to this account.

Two examples; Airport City with a Game-insight account code, and Emergency HQ with their login system in-game.

With Pley

When you add Pley into the mix, the Game Server (database) now attaches PleyGameUserIDs to their users. This information must also be saved to the destination login system.

This is important so when the game starts on web (as a website-level logged in user), the login system can start the game as the right PleyGameUser depending on who is logged in on the website.

📘
Why is this complicated?
As mentioned earlier, the implementation is split into two.
(1) The game starting through a Pley Game User ID. (2) The Destination login server having all the information it needs to start the game with the correct game progress.
This setup allows your game to be launched anywhere on the web (Any website, Discord, in the Pley Game Manager, etc.), without any implementation for each one.