Cancelling a request stops new authentication cookie getting to browser, invalidating all further requests

Question

I am trying to secure my login system using authentication cookies.

If the user tries to access a protected resource they must provide an authentication cookie. If the cookie is valid, the request is authenticated and the resource is returned, along with a new auth cookie for the user.

I rotate the auth cookie as an extra protective measure. In case anyone managed to steal it, it would only be valid until you made your next request.

However, if the user makes a request and the server authenticates it, but before the resource and new cookie reaches the client the user closes the browser, then that means the browser's cookie is not the same as the token in the database. Any further requests can't be authenticated and the user is forced to log in again.

What's the correct approach to this? Should I not send a new token with every response? Should the browser confirm that it received the new token?

Answer 1

The normal way to do this is to have one constant session ID in a cookie. It's a long random number that gets set when the user logs in, and is stored and verified on the server. That's how sessions are handled in most frameworks and languages.

Unless you are doing something special, there is no need to change the session ID on every request. Doing so causes you a lot of problems, like the one you describe. Also, what happends if the user has your page open in multiple tabs at the same time? And so on, and so on.

So unless you have some very specific need to change the token, why would you? It is not a very effective protection against session hijacking (i.e. the cookie being stolen), since an attacker can do a lot while the victim is viewing the page. It is not worth the trouble and the extra complexity it brings.