The end purpose of a login system is to authorize client's messages that he sends to the server and to associate a message with sender.
The prerequisite to do that is that your server is able to uniquely identify a client (an account) which you have discovered (account id).
Now, some do it differently but I strongly believe that account id (or some other unique identifier for an account) should not be publicly available to the client.
How I would do it probably would be:
1. client connects
2. client securely provides username and password
3. after validating login data, server generates a session id (some identifier) which will be used by client when sending messages. This id would be comprised for example of hash(account_id + salt) + validation data + random id + .... Session id is persisted.
4. From now on there is not really a "standard" way how to do it as it depends heavily on: server architecture, network topology of the server etc etc. To list a few options:
5.a) you have a proxy service (single point of entry) that is the only publicly exposed service of your game. Sole purpose of it is to validate session id it is sent to him with each message and forward the message to some internal service (usually, proxy services live on nodes that have at least 2 network interfaces, one public and one heavily firewalled internal one).So, each internal service can automatically trust the message from proxy service.
5.b) Maybe you have direct access from client to your server business logic code. In this scenario you would need to validate session on each message as well but on internal service layer
5.b) ...
TL;DR; You a figured out a good chuck of it but before you go for something like this, you NEED to be conceptually sound with the fact that what you are doing is trying to provide security and client association with messages, which pulls a lot of concepts with them.
Generally it similar as with all login related stuff: <generate_session_id> --> <validate_session_id_on_each_message>
