Комментарии 7
Ужас какой!
Во первых билблиотеки keycloak для спринга - deprecated.
Во вторых спринг поддерживает OAUTH из коробки.
В третьих рефреш токен по хорошему должен быть одноразовым и поэтому вы не можете его использовать.
Хотя о чем это я, аксесс и рефреш токен в кажом запросе вместе. Зачем вам OAUTH вам бы и BASIC автризации хватило - вы ее как раз и сделали.
Здравствуйте, согласен, решение с передачей refresh токена не лучшее. Но смею предположить, что вы недостаточно внимательно прочли вывод статьи. В нем я черным по белому поясняю, что суть статьи не в Best Practice применения OAuth2 протокола, а в том как работают фильтры Spring Security и в каком порядке они обрабатывают запрос. Основной упор заключается именно в этом, а не в том что мы передаем Refresh токен и используем deptecated подходы. Keycloak тут просто послужил причиной разобраться в теме фильтров, поэтому на его примере и написана статья. Что касается вопросов применения OAuth2, еще раз соглашусь, в моем примере приведен не самый лучший вариант его использования.
Спасибо за Ваш комментарий.
Вообще решения вашей проблемы два:
первое: проверять на эндпоинте оставшееся время и если его мало для выполнения запроса то кидать ошибку; ну это-же на самом кленте сделать легко
второе: вам не обязательно использовать клиенский аксесс токен к другим сервисам; вы можете создать для каждого микросервиса клиента и уже с его аксесс токеном выполнять запросы; ясное дело что и этого аксесс токена время нужно контролировать, но тут с переполучением его проблем нет
Если не ошибаюсь, спринг не рекомендует больше юзать WebSecurityConfigurerAdapter.configure, а рекомендует переопределять SecurityFilterChain и WebSecurityCustomizer
Каждый, конечно, сам себе "хозяин - барин".
Но такой подход с перевыпуском access-токенов под капотом микросервисов - это полное переосмысление подхода access-, refresh-токенов в сторону радикального ухудшения.
Refresh-токены, идеологически, должны быть на стороне клиента. Ну в крайнем случае, на стороне API Gateway'я. Передавать refresh-токены в сервисы, это все равно что передавать в сервисы логин/пароль пользователя.
Если сервисы используют скоуп из клиентского access-токена, то тут два подхода, либо сервисы оперируют своими сервисными access-токенами, либо обеспечиваем жизнь клиентского access-токена на все время жизни обработки запроса (а это не всегда означает наличие жесткой проверки exp > current time).
зы
справедливости ради, стоить отметить, что я регулярно встречаю подобные подходы ;)
Путешествие к центру Spring Security