User Authentication w/ Custom WSGI+Sockets Web/Game Server

This is much more of a technical/theoretical question than a "I have a bug please help me" question, but it's a rather important one to ask because when dealing with a user's account credentials, it's important to get it right the first time. TL;DR at the bottom, but here I'll describe my specific use case. I don't currently have a project file.

I have a custom webserver made in Flask that will handle multiplayer. It's using websockets via socket.io, but since the game is non-realtime, it's the most appropriate. It's inevitable that I will have to have user accounts involved; I can't avoid it, so this webserver will handle user authentication in a local database. And yes, I'm not completely irresponsible with this. This Flask server will also handle lobbies and game logic.

I want to have Construct handle the front end/client side of things. It's fairly elementary to have Construct handle socket events and HTTP requests via the AJAX and Socket plugins, but things become complicated when it comes to user sessions; an HTTP POST request to the server will almost certainly return and keep the login token and the information about the user (username/etc) in the session data, and for "remember me" functionality, cookies. It doesn't really seem like I can access that, though, nor can I really guarantee that all platforms will support it.

Am I missing something? Is it actually the case that Construct will use cookies/sessions just fine? Is it maybe just the case that I can't actually access them? For the web version of the game, it will be the case that the web server will return the game from an HTTP GET request to the web server's URL, so the cookies should still be valid for that site, but this wouldn't really be the case for previewing the game within Construct, nor would that (probably) work for deployments of other platforms (due to the nature of the game, though, mobile app support is expendable). Surely, I'm missing something; I know of the Firebase plugin people usually use, but since I'm hosting the server side logic from a webserver, using an external database would be a bigger liability than is really worth, ESPECIALLY implemented in the way the Firebase app is (remember, no logic on the client side; client should not be allowed to query the database at all).

I'm fully able to have the user authentication on the server side work pretty much however is needed, but I most certainly want to do so in the most responsible way possible. Having a POST request over HTTPS would most likely be the most easy and secure way of doing it (because doing that over sockets sounds like a really, really bad idea), but it's something that's just tricky to get right.

I appreciate any feedback for a rather... complex and out-there first post question.

TL;DR: What's the best way to handle user authentication and login sessions for a game with a central server (as opposed to Construct-style P2P) and database?

p.s.: Happy Holidays!~

So I have done some research and theorizing. Don't mark this as answered just yet, but the best solution would probably be to use a JSON Web Token for this using a utility like flask-jwt-extended.

• The server keeps a secret key
• A user wishing to "log in" sends the credentials to the server using an HTTP POST method and a JSON payload
• If all factors of authentication pass, the server signs an authentication token and sends it to the client.
• The token is then passed in the header of any subsequent HTTP requests.

This is something similar to what OAuth does; the token itself can even have a payload of information to be stored, like the username of the user, or a machine identifier, for further verification and security (and to reject invalid tokens). It can either be stored in a temporary global variable or even stored in LocalStorage.

I'm leaving this open to debate in case I missed anything, or there's a better way; I want to stay away from any model that involves the client directly querying the database, so I want to avoid Firebase as much as possible.