I’d like to authenticate users playing my game in the itchio app. When the itch.io app starts a game, it sets an ITCHIO_API_KEY environment variable containing a JWT token. This token can be passed to your game server (e.g. Nakama) to authenticate the user.
I tried to implement this as a BeforeAuthenticateCustom hook, but the JWT exceeds the 128-byte limit on custom authentication data.
Would it make sense to build itch.io authentication into Nakama? As both platforms are based on open-source software, I think they might attract similar crowds. I’m happy to take a look at implementing this if it makes sense.
If not, is there another approach to authentication that might work?
@rcorre It would be great to have Itch authentication support in Nakama. Do you want to prototype the first implementation as a small amount of Go code which hooks into the custom authentication feature in the game server? This way you can experiment without having to change the code in the game server directly.
@novabyte the 128 bytes allowed for custom authentication data is too small to acoomodate the JWT, so I think I’ll have to do it in Nakama unless there’s another approach.
@rcorre I just clocked what I think you’re saying here. You’re trying to place the full JWT string in the user account’s custom ID field, right? If so that’s not how you should typically use JWTs with Nakama’s custom authentication.
Perform validation in the BeforeAuthenticateCustom hook as you say, but when/if this validation succeeds you should swap the JWT string from the request for the user ID the token belongs to. This is usually in the JWT’s sub claim, but might vary depending on the token issuer.
It’s unlikely the swapped out user ID will be over 128 bytes so you should be good to go.
@zyro I think the problem is that we validate the JWT passed in as the id field which would be swapped out in the before hook for custom authentication to be less than 128 characters:
We may want to lift this restriction otherwise it could be an issue with other custom authentication solutions that take advantage of the before hook to apply the validation and swap the token for the authenticated player ID passed forwards to be stored in Nakama.
I suggest we move the input length check to the core function for this authentication option in the server.
I’ve had another look at the code and I’m wrong. The before hook for the authenticate custom function will run before the input validation is done. I think you have all you need to experiment with Itchio support @rcorre
Aha, you are so right! I saw an error about 6-128 characters and assumed I was over, but in fact I’m under, as the itchio ID can be a 5 digit number. That’s more easily solved.
At this point I’m reasonably far on an implementation inside Nakama, would that still be interesting?
@rcorre I think it would be great to add Itchio support as an official social provider though it’d also be good to try the PoC you’ve shared first. There’s a few additional details which have to be handled with a new social provider:
Requires a database migration added to the schema.
Must implement link and unlink operations as well as the authenticate function.
Must handle the field in the console API.
Must update the Nakama devconsole to reflect the new field.
A couple of these pieces of code will change once we’ve released Nakama 3.0 which is scheduled for January 2021. The server release is fully backwards compatible but we’ve revamped the console UI entirely.
@rcorre I took a look at the initial code for the Itchio integration you put together as a hook over the custom authentication in the game server. A few notes about it as small feedback:
I’d recommend you treat your code like a Go package which can be imported by others. You’d have an entrypoint which takes the initializer and other arguments used to set up your logic. Have a look at this code for an example.
Don’t forget to call close otherwise your IO from the HTTP request will leak.
For errors you want to return to the client with your own HTTP status code use the runtime.NewError(message, grpcCode) function in the runtime. You must use the GRPC code which will be converted to the HTTP status code. For example GRPC code 3 is “Bad Request” (400).
Thanks for the feedback! I went ahead and finished up the builtin implementation since I was pretty far on it anyways, the PR is here: github dot com slash heroiclabs/nakama/pull/510 (the forums won’t let me post that link for some reason).
