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?

  • 2
    It is not clear why do you issue a new token after every request in the first place. Additionally - you could have two valid tokens and invalidate the previous one only after the new one got actually used. Jun 25, 2019 at 10:53

1 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.

  • Regarding the multiple pages thing, there is a table of auth tokens with the user, so they can be signed in from multiple locations. The reason I make a new cookie is because I think I read that somewhere. How often should I refresh it? It can't be safe to keep it around forever.
    – Zotoaster
    Jun 25, 2019 at 11:01
  • 1
    @Zotoaster Check. You can solve a lot of this, but is there any real need to change the token?
    – Anders
    Jun 25, 2019 at 11:04
  • The reason I did it is incase anyone managed to steal your cookie it would only be valid until you made your next request. But since I'm sanitising all the user inputs I don't think anyone can get your cookie (I might be wrong?). I just did it as an extra protective measure but it's not worth it with the problems it creates.
    – Zotoaster
    Jun 25, 2019 at 11:11
  • 1
    @Zotoaster I see your point, but I don't think it is a very efficient way of protecting yourself against session hijacking, and it will cause you a lot of problems. So I would not do it.
    – Anders
    Jun 25, 2019 at 11:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .