Каков наилучший подход к реализации безопасности для запросов гостевых пользователей в веб-API без отслеживания состояния?

Question

Существует существующий веб-API с отслеживанием состояния, который необходимо заменить реализацией без сохранения состояния.

В настоящее время существуют следующие типы активных пользовательских сеансов:

1. Временный гость user (пока ничего не стоит экономить). У пользователя есть идентификатор, но нет пароля.
2. Постоянный гость (с ним связаны некоторые ценные данные, например, корзина, избранное и т. Д. c).
   Пользователь имеет идентификатор, но не имеет пароля. Идентифицируются и аутентифицируются с помощью файлов cookie. Сессию можно преобразовать в тип 3 путем регистрации. Сеанс сбрасывается, и при входе в систему запускается новый сеанс типа 3.
3. Постоянный зарегистрированный пользователь , который вошел в систему. У пользователя есть идентификатор и пароль. Идентифицированы и аутентифицированы с помощью учетных данных или файлов cookie. Сессия прерывается при выходе из системы.

Итак, я ищу лучших практик для реализации аналогов для этих трех типов сессий без сохранения состояния.

Похоже, использование токена JWT - довольно распространенная практика для аутентификации без сохранения состояния. Тип 1 выглядит довольно прямолинейно, поскольку запросы не нужно защищать, поэтому токен не потребуется. Тип 3 имеет множество примеров в сети генерации токена JWT на основе учетных данных пользователя. Тип 2 - вот что меня смущает, так как у пользователя нет пароля. Я предполагаю, что можно было бы сгенерировать какой-то пароль для постоянного гостя на бэкэнде и использовать его для генерации токена. Или есть лучший способ справиться с этим?

Также я пытаюсь выяснить, что должно произойти с токенами, когда

• гостевой пользователь регистрируется (в настоящее время сеанс преобразован)
• гостевой пользователь входит в систему (в настоящее время начинается новый сеанс)

Answer 1

Мы выбрали следующее решение:

1. Типы сеансов . Мы сократили три типа сеанса до двух: гостевой (не постоянный) и пользовательский (постоянный). Ценная информация о гостях теперь хранится в файлах cookie.

2. JWT . Токен хранится в защищенном хранилище HttpOnly ie. Токен содержит идентификатор пользователя, тип пользователя, дату выпуска и срок действия. Токен зашифрован с использованием секретного ключа и устанавливается в качестве ответного устройства ie на бэкэнде, когда создается новый гость или когда пользователь входит в систему.

Итак, теперь мы находимся в промежуточном состоянии, где мы в нашем монолите есть как API без сохранения состояния, так и API с отслеживанием состояния, и одновременно работают два механизма безопасности. Следующим шагом является извлечение служб без сохранения состояния.

PS Если вы столкнетесь с подобной проблемой, вы также можете рассмотреть возможность использования шлюза API с отслеживанием состояния перед службами без отслеживания состояния. Это дает определенные преимущества, вы можете найти в Google дополнительную информацию.