Как сбрасывать сессию авторизации пользователя при смене пароля или для выхода на других устройствах?

Question

[Лев Салатов]

Доброго времени суток!

Логика авторизации:

• в куке хранятся токены в формате selector:validator
  
• в БД: selector, хэш validator и время жизни авторизации
  

При успешной авторизации: создается кука с токенами и запись в БД, а также сессия с id пользователя.

При входе на закрытые разделы:

• есть сессия - пускаем
  
• нет сессии - проверяем данные в куке и БД, если ок - создаем сессию с id пользователя и пускаем.
  

Как в данном случае поступить при следующих ситуациях:
1. Смена пароля
Если сменился пароль, можно почистить БД и создать новую куку, но как быть с сессиями, которые хранятся на других устройствах? Понятно, что сессия умрет, но до этого момента доступ еще будет.

2. Кнопка "Выйти на других устройствах". Опять же, можно почистить БД и создать новую куку и снова вопрос о сессиях на других устройствах.

Есть мысль убрать проверку на наличии сессии в закрытых разделах и каждый раз делать запрос в БД на получение актуальных токенов, но на проект большие надежды)) вдруг будет большое количество активных пользователей, и каждый переход в личном кабинете - запрос не только за информацией, а также и запрос для проверки авторизации.

Пожалуйста, подскажите, как можно поступить в данной ситуации?
Если возможно, без JWT, так как на старте проекта не понятул по знаниям, да и сейчас не очень уверен, что смогу переделать.
Заранее спасибо!

Comments

[Максим Федоров]

сделайте токен в БД
при смене пароля или логаута — удаляйте его
при входе — проверйте входящий токен из куков

[Лев Салатов]

Максим Федоров, спасибо за ответ!

Answer 1

[rPman]

Сохраняй идентификатор сессии session_id в базе данных с привязкой к пользователю (1 к М так как пользователь может авторизоваться с разных устройств), при необходимости отзыва доступа (смена пароля или пользователь пожелал) просто удали определенную по этому идентификатору

session_id($sid);
session_destroy();
session_commit();

механизм сессий в php это просто готовое решение простой базы данных в памяти, и оно становится неудобным при увеличении количества серверов в бакэнде, поэтому возможно сразу все хранить в базе данных кажется более удобным.

кстати в настройках php можно указать как хранить сессии session.save_handler например redis или memcached, это значит централизованно и немного проще управляться