Обработка пользователей, не вошедших в приложение Angular с помощью Keycloak

Question

Я создаю приложение в Angular, которое использует Kecloak для входа и авторизации. И вошедшие, и незарегистрированные пользователи (анонимные) получат доступ к одной из частей приложения. Действия в этой части приложения будут отправлены в остальные службы и зарегистрированы (на основе токена на предъявителя), так что каждый пользователь будет иметь доступ к истории своих действий. В случае незарегистрированного пользователя до конца сеанса пользователь также видит историю своих действий.

Я думал, что если пользователь не вошел в систему, тот же пользователь войдет в систему. фон (тот же пользователь для всех анонимных пользователей), например, анонимный, и его действия будут сохранены вместе с токеном keycloak (session_state). У каждого незарегистрированного пользователя будет свой токен

. В этом случае это хороший подход или есть лучший?

Answer 1

Я думаю, что ваш лучший выбор здесь, и его легче реализовать, это вообще не входить в систему анонимных пользователей. Что-то, что вы хотите сделать, так или иначе против рабочего процесса методов OAuth.

Если вы хотите отслеживать незарегистрированных пользователей, ваш лучший выбор - сделать это с помощью браузера cook ie с идентификатором SESSION, многие серверные платформы делают это по умолчанию. Затем для сохранения действий вы можете иметь оба поля, одно из которых относится к имени пользователя (может быть обнуляемым), а другое - для идентификатора СЕССИИ.

Answer 2

Спасибо за ваш ответ. Я сделал частично, как вы пишете. Зарегистрированный пользователь распознается по имени пользователя или идентификатору пользователя, полученному из маркера носителя. Однако для незарегистрированных пользователей я сделал серверную службу отдыха, которая возвращает acces_token и устанавливает для себя httpOnly cook ie со значением reresh_token. Когда angular запрашивает сеанс незарегистрированного пользователя, служба отвечает токеном, основанным на refesh_token от повара ie, или создает новый сеанс и устанавливает повара ie с refresh_token. На мой взгляд, это решение имеет ряд преимуществ:

• Я легко могу контролировать доступ анонимных пользователей к приложению (проверить количество, заблокировать доступ)
• прямого доступа нет в мой API (каждый должен получить токен из бэкэнд-сервиса раньше)
• повар ie защищен, так что я не могу прочитать его из javascript из внешнего интерфейса
• является согласованным решением для пользователей, вошедших в систему и не зарегистрировавшихся - я всегда использую маркер keycloak для распознавания пользователей - в случае зарегистрированных пользователей это userName, а в случае незарегистрированных - session_state.

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