Yes, you can use something like JWT. Another option is something like a Kerberos ticket. Another option is something like a web session cookie token.

The GAME server generally keeps the state of the player in RAM as long as the player is connected. When the connection drops, and occasionally when the player does something worthwhile (gains experience, or gains important loot, or whatever) the server typically checkpoints the state back to the storage system.

Note that the JWT should not contain the actual player state (as found in the database) because that would allow someone to log in and get token A, then log in and get token B, then play on token B, and if something bad happens, re-use token A to revert state back to the old state. The token should only implement authentication, and the actual data is transferred on the back-end between the game server and the storage system (database, file server, three-tier web service back-end, or whatever.)

A TCP connection is believed to be hard to hijack unless you have nation-state level access to the network, or are part of the ISP/transit chain for the connection. A TCP socket running TLS is believed to be hard to hijack even for those kinds of actors. Thus, if you either trust that the NSA or Chinese government don't care about your game, OR if you're using TLS for your TCP connection, using the socket as a persistent identifier for the player for as long as the connection is alive, is reasonable.

Also, for real-time games, you shouldn't think of each key press or action as a "request." Instead, think of the world as a large state machine, that evolves based on inputs/stimuli, where one such input is the passage of game time (tied to real time.) Player commands are messages that provide inputs to this state machine. The player object state is a subset of the large world state machine, and changes to the player state are communicated using messages going back to the client machine. An important architectural realization here is that there is no direct 1:1 (or even M:N) relationship between "input messages sent by the client" and "world change updates sent to the client" -- they are separate, unidirectional real-time message streams. Some of the individual messages may, at a higher level, end up being in the request/response form, but those are to be viewed as one of many patterns on top of the two directional message streams.

There is no way to identify players across multiple/different connections.

When the TCP connection first comes in, you need to identify the player. You can do this by requesting the name and password, and check those against some data store, or you can have some other service that checks name/password and issues a token, and the new connection then verifies the token (rather than having to verify name/password.)

Which model works best for you depends on specifics.