How to store session properly when developing JSON API?

But how much is it right?

There simply is no other approach. You somehow need to identify the user API. For any indirect evidence, you cannot identify it - several consumers can sit on the same IP, the User-Agent is not in principle, and indeed it is just a replaceable header and no more.

Therefore, with each request you need to pass a certain identifier that can help you find the user. There are a few subtle points:

• It should not be the user ID itself (otherwise the whole mechanism breaks through ID hijacking, and nothing can be done with the hijacked user except to kill him)
• This identifier (or the mechanism associated with it) must unambiguously confirm the correctness of the session or be transmitted exclusively over a secure channel (HTTPS), otherwise it can be equally hijacked and presented as an incorrect user.
• Identifiers should be considered consumable in the application: you can always bang them and create new ones so that any stolen identifier can be reset to zero immediately after the theft is detected

The generally accepted approach is considered to be the transfer of an access token in an arbitrary header ( github , google , amazon s3 ). One way or another, the information for authentication always remains in the headers (it does not belong to the query parameters and the request body itself), so there is, in fact, no particular choice either. The token is stored on the device, in case of panic, the user deletes the token (using the same access token)

The last paragraph - about the confirmation of the correctness of the session transmitted over an unprotected channel.
In case there are concerns for intercepting a token during its transfer, it is necessary to sign outgoing requests one way or another. To do this, you can use a full-weighted or lightweight challenge-response authentication, the meaning of which can be reduced to the fact that the server and the client give riddles to each other riddles that only they themselves can solve. In the simplest version, the server can write out a token consisting of an identifier and a secret part (encryption key), which is sent to the client once when creating the token (the client can also transfer some secret, but we believe that the server can always be trusted). After that, all messages from the client to the server are either fully encrypted with the received key, or they contain in the additional header a signature generated on the basis of the key and the request body that the attacker cannot forge without stealing the secret key. This, however, does not protect itself from:

• Replay attacks (for example, if a user sends a request to delete the last record, then an attacker can generate another hundred such requests and completely clear the user's history). The simplest solution is juggling with timestamps (eg not accepting requests older than 5 seconds), but with the slightest problems with synchronization it shoots in the leg.
• Physical withdrawal of the key from the client. It is usually considered that it is impossible to protect against this, and this moment is simply ignored.
• Interception key at the time of writing a token (so it is better to get HTTPS after all). With open traffic, you can use the Diffie-Hellman algorithm and analogs, but it will take more time than writing the application itself.
• Key calculations when using an incorrect algorithm (eg if the key does not rotate and if the attacker knows that JSON is always used, then he, knowing that the last character is always } or ] , can calculate the key by comparing requests of different lengths). Again, it is easier to take HTTPS, there are alternative methods, but I will not tell them in order not to miss an important point.

upd. There is a certain standard json web token , I myself have not yet read it.