In my app server's authentication implementation, an authentication token is generated for every user that has logged in. According to some highly recommended security tips (Implementing Secure User Authentication in PHP Applications with Long-Term Persistence (Login with "Remember Me" Cookies)), this token must be updated frequently, at a certain interval or even after every authenticated request. Especially in web authentication, the token is set or updated with the "set-cookie" header in an HTTP response. However, there is a chance that:
- The connection is down or the client process is killed before the response is sent back and processed, and the server cannot judge whether the response is actually received and saved by the client. (according to Finding out if a message over tcp was delivered)
- The client (especially a browser, an HTTP client) sends multiple requests in parallel connections to the server and the server generates several new tokens, updates the database atomically, and sends them back in separate threads. Due to network delays, the arrival order of such new tokens might not be the same as the order in which they reach the client, so the client might not keep the same newest token as that in the server database.
How do those successful app services handle the 2 issues mentioned above? Is there a good and simple solution for them?