Я понимаю, что этот вопрос был забит до смерти, потому что я прочитал множество статей, вопросов и идей о файлах cookie и сеансах, а также о JWT и так далее. Надеюсь, этот вопрос не будет закрыт вовремя, чтобы получить отзывы о том, как я пытаюсь его решить.
Статьи, на которых я остановился, -
Статья Чарльза Миллера "Передовая практика использования файлов cookie для постоянного входа в систему"
«Запомнить меня» - долгосрочная постоянная аутентификация
Получение аутентификации токена в одностраничном приложении без сохранения состояния
Итак, вот мое мышление:
Зарегистрированные пользователи посещают сайт, базовый сеанс создан.
- Отслеживайте взаимодействия с пользователем (например: добавляйте интересующие вас товары в корзину).
Не авторизованный пользователь регистрируется или регистрируется.
- Если сеанс существует, перенесите данные сеанса по мере необходимости.
- «селектор: валидатор», как в статье 2 , селектор помещен в полезную нагрузку JWT, валидатор - в заголовок JWT. «селектор: валидатор» сохранен в БД.
- постоянное значение добавляется в заголовок как 0 или 1.
- Если флажок «запомнить меня» установлен, срок действия JWT установлен долгоживущим; если не отмечено, JWT exp 15 мин.
- JWT подписан и разделен на две части, как в статье 3 : заголовок и подпись отправляются в виде долговременного безопасного файла cookie только для http, полезная нагрузка отправляется в виде читаемого файла cookie с чрезвычайно коротким сроком действия.
Селектор и валидатор должны действовать как идентификатор серии и токен из статьи 1 .
Так как это не SPA, и я не использую Angular, я думаю обойти заголовок Bearer для аутентификации всякий раз, когда страница загружается, получить читаемый cookie до того, как он истечет. При последующих переходах по страницам перехватите щелчок привязки, установите файл cookie с содержимым из читаемого файла cookie и перейдите к этой навигации. Насколько я понимаю, одним из основных способов предотвращения CSRF является установка клиентской стороны заголовка Bearer, поэтому установка cookie с помощью Javascript будет такой же стратегией?
- Защищенный запрос страницы на сервере, JWT восстановлен и проверен, не истек ли он.
- Если срок действия истек, а 'persistent' = 0, перенаправить логин.
- Если срок действия истек, а 'persistent' = 1, проверьте селектор: валидатор для БД.
- Если селектор и валидатор совпадают, создайте и обновите БД с новым валидатором и подпишите новый JWT.
- Если выбран только один селектор, это означает, что cookie использовался другой стороной, и эта сторона получила новый валидатор. Полностью аннулируйте этот селектор и перенаправьте на вход в систему.
- Если ничего не найдено, перенаправить на страницу входа.
Я понимаю, что это не относится к XSS, но если XSS является основной проблемой сайта, все остальное уходит в окно.
Какие проблемы с этим рабочим процессом? Некоторые способы улучшить? Или вообще убрать за другую альтернативу? Я знаю, что это очень широкий и общий вопрос, но я ценю любые отзывы, поэтому я могу перестать бороться с этой проблемой в своей голове и вернуться к разработке сайта. Спасибо.
Редактировать: причина перехода на JWT заключается в том, что сайт не имеет состояния ... не требуя поиска в базе данных при каждом запросе страницы. Поиск будет происходить только каждые 15 минут, когда истекает срок действия JWT, независимо от того, постоянный вход в систему или нет. Я предполагаю, что использование обычных файлов cookie и установка валидатора, идентификатора пользователя и истечения 15 минут в долгоживущий и безопасный файл cookie только для http будет работать без JWT ...