Hi @maximlus, welcome to the forums
Logins need two things:
* A way to track logged-in status
* A way to set logged-in status
You can track logged-in status on either the client or on the server, but you almost always want to track _something_ on the client. The complication comes from identifying _who_ that client is, and that you can not trust clients.
A common flow for a single-page application (your game probably is this) would be something like:
* Hit your webpage holding your game
* Navigate to log-in screen
* Enter log in details (e.g. id/email, password)
* Send those to your server. Check the details, if correct, generate a token, store it, send it to client.
* Client stores this token (local storage is fine) and uses it to make subsequent requests or to actually enter the game.
* Next visit, when client boots up (after hitting the url), check local storage for a token, maybe send it to your server to check it is still valid, become logged in.
This flow means you have to store 3 things:
* id/email and password details (server)
* valid tokens (server)
* logged-in status (client)
Valid token status dictates logged-in status i.e. you should probably check the token is valid before assuming that it is.
Tokens normally have two things:
* An expiry
* Are revocable
An expiry means they will expire, you don't necessarily need to store this on the client, i.e. when the expiry date is hit then delete from server storage, when a client tries to use it, that operation will fail and you'll direct the user to a place where they can enter their details to generate a new one.
This system also means that if you think anything is compromised (or problematic) then you can revoke a token. You could go a step further and associate a token with a user explicitly which gives you more control if you want to boot out a user, i.e. you revoke their token so they stop immediately, and you stop them from being able to generate a new one.
It is normal to do this link between tokens are users, check out JWTs. If your game requires accessing authenticated endpoints (getting levels, scores, anything really) then using a token to do the auth stuff is quite nice i.e. your services _could_ inspect the token and respond appropriately for that user (or user type) i.e. to get the _next_ level, you wouldn't have to ask for it from the client (remember, don't trust clients), you could hold current level on the server and your endpoint could inspect the token, inspect the current level (and completion status maybe) and return the next level.
There are lots of services out there that can handle these flows (and more complicated ones, such as 2FA) for you. It's worth looking up how they work and if they would work for you. Unless you want to code this all up and have to deal with holding emails or other personally identifying information (or even user tracking).