Skip to main content

On Sale: GamesAssetsToolsTabletopComics
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

How exactly would authentication work with multiplayer games + the app

A topic by mid created Mar 01, 2017 Views: 3,002 Replies: 5
Viewing posts 1 to 3

Using https://itch.io/api/1/jwt/me Itch gives me information about the player, however what would I give the server to authenticate the client?
And how would the server auth the player?

Nothing?

(4 edits)

Well I haven't got my application set up yet, but from reading the documentation it seems as though:

1. Use https://itch.io/api/1/jwt/me to get information about the player (I'm assuming you're already doing this)

2. Then call the API described here to verify the user is legit (if your game requires a user to have purchased the game, or obtained a key from you some other way)

3. You should now be confident in your game client that your user is valid (and owns the copy of the game if you decided to do #2). You should be able to pass the same ITCHIO_API_KEY environment variable to the server, and have the server also perform #1 & #2 again so it can also trust the player is legit. The key is valid until ITCHIO_API_KEY_EXPIRES_AT environment variable so you should be able to auth using that key until it expires. I don't yet know how long that timeframe is though.

I haven't set my game up to use the app manifest yet, since I've only just started using Itch. I'm still reading documentation about different API functionality and just wanted to give you an idea of how it all seems to flow in my mind.


If you want to get really really fancy once you've got the basics:

There are also some other cool ways you can use to make sure that the API key you've been given doesn't go to waste if the expiration they give you is a short timeframe and you don't want you user to have to re-launch your game. You can also create your own verification backend that verifies, and translates Itch API keys into session keys that YOU control. You can then use those session keys to authenticate with your server, and the server verifies your internal session keys. You can even get crafty and set them up to rotate around so the key can only be used once and refreshes for every request in order to prevent replay attacks.

Can't anybody pass any user that has bought the game?
That's bypassing the check.

(2 edits)
Can't anybody pass any user that has bought the game?

Nope.

The Itch application passes an environment variable to your application that contains a session API key. It's unique to the user and dare I say impossible to forge. You then take that api key, and pass it as an authorization header to the https://itch.io/api/1/jwt/me endpoint. If you get a user JSON object back, then the key is valid and you can trust that they are who they say they are.

If you get an object back that contains anything else, like an error, then it's not valid.

I finally got this set up tonight. Here is a sample of what might be returned upon verifying a key against the API:

POST /api/1/jwt/me HTTP/1.1
Host: itch.io
Authorization: The ITCHIO_API_KEY environment variable sent to your game
{
  "user": {
    "gamer": false,
    "id": 509014,
    "url": "https://dobydigital.itch.io",
    "username": "dobydigital",
    "developer": true,
    "press_user": false
  }
}

Here's what it might look like if you send an invalid token through:

{
  "errors": [
    "invalid base64"
  ]
}
{
  "errors": [
    "header not HS256"
  ]
}

Basically anything with error in it is invalid, so don't authenticate the user.

The only way someone is gonna get that API key is if the player launching the game figures out what the key is, by looking in the environment, and gives it to someone else.

That's why I mentioned you can get fancy and prevent replay attacks by verifying the API key against a service that YOU own. You can prevent it from being used again by storing it in a database somewhere or something. Get creative.