No, there is only one cookie.
Server side, you have two values. One is the remember_me hash, that should be generated when a user logs in, is stored in the remember_me cookie, and is used to lookup the user and do an automatic login whenever the cookie is presented. It should be reset when a user logs out, which will invalidate any remember_me cookie issued before.
The second thing that is suggested here is to store a second hash (the token), which is rotated on a regular basis, and is stored with the user as well, but a history is kept (for example the last 31 days worth of tokens). The last issued token is also stored in the remember_me cookie.
Now when a user presents itself, you can have the following situations:
* no session cookie, no remember_me cookie: public access, the user needs to login
* session cookie: login retrieved from the session, user is logged in
* remember_me cookie, invalid hash: public access, the user needs to login (I would issue a warning here)
* remember_me cookie, valid hash, last issued token: login retrieved from the hash, user is logged in
* remember_me cookie, valid hash, other issued token: login retrieved from the hash, user is logged in, warn the user the account was hacked!
* remember_me cookie, valid hash, invalid token: public access, the user needs to login (I would issue a warning here too)
The idea behind the token store is that you can detect that the remember_me cookie was stolen and used by someone else because the login by the hacker has caused the token to rotate, so your original cookie has a valid token, but not the last one issued.
This warning system depends on your token rotation interval and how long you store the tokens.
If you don’t store multiple tokens but only rotate, you effectively have the last situation. And you have to decide what to do in that case: assume it’s a valid login because the hash matches, or assume it’s a brute force hacking attempt of some sort (with a random token) and deny access.