What does the logic of a simple authorization system with “sign out on all devices” look like?

Question

PHP

At the same time, using only PHP, MySQL, sessions and cookies ( without redis, memcache, etc. ).
It’s just that when I started writing password recovery (essentially a reset, a new one comes to the user’s mail), I realized that logically there should be an “exit on all devices”, but I don’t understand how to organize it.
Before that, admins were somehow not particularly needed, so I used them only for my smallest needs with a simple auth=true entry in the session. When the browser was turned off, the session was lost. I know that it is possible to increase the life of the session, but it seems like they don’t recommend it, it’s better to write later to restore them by cookies (additional ones, apparently still set, not session ones) or tokens in the database (didn’t come across). So I wanted to ask what where to write something in the end, so that you can then distinguish between user authorizations from different devices, and so that they can be demolished at once when resetting the password?
For now, I can visualize it like this:

1. Authorize -> fill in the session, write an additional (long-term, for example 3 days) cookie with a random string (mycoockie = "dsf34Nrty4d4dftlk5r4g5") to restore the session, write the same string to the database in the sessions table ("dsf34Nrty4d4dftlk5r4g5") and ID the user who owns the session.

open trail. page:

2. If there is a session -> we are working (or also constantly check that there is some relevant data in the database, because maybe I am an attacker, and the real user used the password reset, i.e. I should be thrown out immediately).

3. If it disappeared (they closed the browser or 24 minutes of inactivity, which seems to be the default for sessions), check the cookie (mycoockie), and if it contains any random string. -> we check the presence of this random line in the database, if found, then we restore the user data by ID opposite this line.

Answer 1

I have it implemented as follows:
There is a sessions table in the database with the fields current_session, long_session, user_id and login_time.
Upon successful login, two random strings are generated. The first one is written to the standard PHP session and will be the current_session. The second is written to the user in the session cookie, and the hash of this string will be long_session. user_id - user ID, login_time - login time.
Checking if the user is logged in is done as follows:
1. If the user has an active PHP session, check if his current_session is active, if yes, then the user is logged in.
2. If the user does not have a current session, but the session cookie is set, then we look for a hash from it in the database. If there is a record and less than the specified amount of time has passed since the last login (I use less than three months), then by user_id we take the rest of the user's data and create the current session, the user is authorized.
When logout, we simply clear the current current_session and long_session. If you need to log out everywhere, then we clear all these values ​​​​by user_id.
This approach allows you to strictly manage sessions using the database, but at the same time, the standard PHP session mechanism allows you to store a variety of information, such as csrf tokens, without cluttering up the database.

Answer 2

Change of an uchetka token on the server and resulted at the following request.