как считает ?
Мне кажется что безопаснее не сообщать клиенту Id user
лучше id
Можно хранить session uuid. То есть в кредах специальный айдишник который после перевыпуска токенов перезаписывается
ну или взять готовую штуку типа keycloak или сервис и не ебать голову.
ограничение такого подхода еще - система которая валидирует токен должна так же знать session id. а в этом случае есть вопрос - а нахер токены вообще. http-only куки с идентификатором сессий и готово. не надо сессии эмулировать токенами
Ну jwt токен можно комбинировать refresh токеном
С одной стороны да, но если есть какая то кастомная бизнес логика, например возможность менеджерам запрашивать восстановление пароля для пользователя, это вряд ли получится в keycloak описать
https://bestestredteam.com/content/images/2018/12/image-3.png
кейклоак позволяет запрашивать восстановление пароля? да. Кейклоак дает тебе API? да. Авторизация действий у тебя будет в keykloak - скорее всего нет. То есть мы говорим про отдельную штуку для этого бизнес кейса интегрированную с кейклоаком
Поч не получится? Всё получится! Верь в себя!
мы кстати юзаем схему с короткоживущим access-token + refresh token для админки, фронт которой взаимодействует с несколькими бекенд сервисами access-token содержит список подсистем, на которые есть доступ у юзера, и его ид; валидируется на всех бекендах отдельно на каждый запрос - сессия на бекендах не хранится refresh-token используется для получения новых access-token-ов через сервис аутентификации. Выдается одноразово при аутентификации, а также при каждом рефреше access token-а. refresh token хранится в HttpOnly Cookie, access token передается сервисом аутентификации в body ответа.
если измениться список доступов к подсистемам, то как поступаете если пользователя больше 1 активной сессии?
Никак, через некоторое небольшое время у юзера список обновится
Обсуждают сегодня