Room Based User Authentication without having a user database

Question

I'm looking to make a web-app/game where people do not need an account to play, but the game is room based, and once the game has started the room closes. I'm most familiar with Spring/REST services as a back-end.

The best example for this type of system is the Jackbox Games backend (Quiplash, Drawful, etc). The way theirs works is:

1. Go to landing page
2. Enter desired username and also a "room code" of the room to join (note: anyone can join, no account needed)
3. Click start game when all users are in
4. Play game, no more users can join

Anyone have any ideas of how to approach this?

I'm familiar with having users authenticate against a database on a login call to the server. And also I'm pretty familiar with how I might pass around payloads via JWT, but I'm having a bit of trouble piecing together how I might create the rooms and then close them. Also keeping users "logged in" until the game ends.

Any suggestions would be wonderful.

Thanks.

Answer 1

Keep a list of room codes for opened rooms, and when the game begins, remove the room code from the list to close it

You can keep the room codes for currently open rooms on the server-side in some sort of a list. Any room which is open for joining will have its code on this list, whereas any room which hasn't been created yet or is not open for joining does not have an entry on that list.

Room joining flow

1. When user enters the username and room code, you check whether the room code is present on the "open rooms" list. If it does, you add the user to the list of users waiting for the game in a room to begin.
2. When all players have joined, the game begins. You close the room by removing its entry from the "open rooms" list. Players start playing now.
3. No-one can now join the room, as the "open rooms" list no longer has an entry for it. The room code is no longer valid for anyone who wants to join, so the room is effectively closed to everyone outside of the game session.

(Note: this assumes that there are no passwords for individual user accounts. In this case a separate user authentication feature needs to be added, as otherwise users can pick any username they want.)

Answer 2

From your comment on the other answer you are saying that you are primarily having trouble about how to keep the user logged in.

From the games I've worked on, a standard practice is to create an anonymous player account when the game is first loaded using a randomised identifier and secret. You then log in by providing these access details to the backend server in exchange for a session token that can be used to authenticate subsequent requests. Session tokens are usually time-limited and must be refreshed using the original identifier and secret.

You've mentioned JWT tokens - they are indeed a good way to handle session authentication for these types of services. One of the main benefits of JWT is that the tokens are stateless, so you server does not need to maintain a list of valid tokens - this has scaling benefits as there is no need to maintain a central store amongst all your servers.

The JWT standard also contains built-in support for token expiry times. There are many libraries available for validating and constructing JWT tokens. One the disadvantages of JWT is that there is n oway to invalidate an existing token, aside from maintaining a list on your server and checking that list every time you validate a token.

Alternatively, you could also use an existing game backend service to store your player accounts and your room list. These will come with login and authentication support already and could simplify what you are trying to do. ChilliConnect offers both these features. Full disclaimer: I work for ChilliConnect.