Allow RPC registration without authentication

[thegoldenmule]

Summary

We would like to be able to register RPCs that bypass authentication and are publicly accessible. Currently, all RPC registered through RegisterRpc require a user to be logged in or an HTTP key be provided (for S2S calls). However, there are many use cases for un-authenticated clients to hit RPC endpoints.

Here are a few examples:

1. Nakama serves localization versioning information, which the client needs to be able to find the appropriate login button.
2. Users are broken into cohorts based on device id, before login occurs. This is fairly standard to test different first time user experience flows.
3. Before a user creates an account, they can see a live leaderboard to excite them about playing.
4. Releasing a game-specific public API for developers, hobbyists, and tinkerers (see Fortnite API Example).

Workarounds

There are a few different workarounds we have considered:

• Making a new server that effectively proxies these requests. It has a public API, then sends requests along with the HTTP key to Nakama. This, unfortunately, is a time-consuming and resource-intensive alternative. We would need to deploy and scale this service ourselves rather than rely on Heroic Cloud's builtin clustering, which solves the same problem.

• Including the HTTP key on the client and making our own secret. This effectively compromises the HTTP key and opens every HTTP RPC endpoint for public access. We would then need to go through all of these and make sure the relevant check exists. The issue with this approach is not so much the work of adding checks, but making sure they stay in place. In many server frameworks (Rails, Express, ASP.NET, etc), this would be applied as policy middleware, and could be enforced across the board to avoid accidental security breaches. Nakama, to my knowledge, doesn't support this type of middleware strategy, so it would be up to us, every time we author an RPC function, to add that security check. Additional boilerplate for every RPC function is non-optimal in a number of ways.

Conclusion

These methods have significant drawbacks and it would be optimal to provide this functionality as part of Nakama. We are open to work with Heroic and contribute, but don't want to spend time on a PR if it will be rejected out of hand for some other reason.

[novabyte]

@thegoldenmule Thanks for the detailed feature request. I think these requirements are very reasonable and will have a discussion with the team internally to determine whether there's tradeoffs I've missed. I'll leave a note here once that's happened for us to push it forwards 👍

[thegoldenmule]

@novabyte Thanks for working with us. Again, we are happy to put some engineering resources on this so please let me know how we can help out. I understand that having us do the work, specifically for a security related feature is dicey.

[dsnopek]

Another use-case for this is triggering a "forgot my password" workflow. Otherwise, you need to have another server-side script somewhere just to pass this request on to Nakama (with the http key).

[thegoldenmule]

Hi @novabyte, has there been any progress here? We are becoming more and more blocked by this issue. Again, we're happy to work on a PR-- but if it won't be adopted and part of a scheduled release (i.e. we need to be able to use it on Heroic Cloud) then we need to know so we can look at other options.

[novabyte]

@thegoldenmule We've not kicked off any development on it yet. We're happy to review a pull request and consider it for inclusion in a future release. I think the only considerations to be made are on how its attached to the current GRPC mux and to make sure that the interceptor logic which governs authorization of requests is fully backwards compatible with any change you introduce.

[Kareem21227gg]

@novabyte Hi, any update on this?

[novabyte]

@Kareem21227gg This is still on the roadmap but we've not kicked off development on it yet. If you're interested to open a pull request on it we'd be happy to review it.

[Kareem21227gg]

@novabyte for my usecase, I'm gonna use httpKey to validate the requests, but in the feature, I'm gonna implement this for sure. finally thanks for this great server!

[novabyte]

@Kareem21227gg An alternative to using the server to server (s2s) http key would be to create a user within your InitModule logic which you can use as the single user to authenticate all clients as when you want to run these specific "unauthenticated" RPC calls. It's not ideal I agree so should be improved.