Comments 4
В Вашем примере логика авторизации размазана на несколько сервисов (gateway, resource). Обычно, такие вещи делают только в одном месте, а именно на стороне шлюза. Бизнесовые сервисы уже стоят за шлюзом и из большого интернета к ним не попадешь, поэтому там не так важно проверять авторизацию (разве что передать токен для вытягивания из него пользователя, но без проверки подписи). Непосредственно проверку авторизацию и редирект на логин логично сделать только на стороне шлюза.
И еще поделюсь личным опытом, использование конфиг сервера не очень удобно. Были проблемы при сборке образов сервисов на момент когда конфиг сервер еще не поднялся (docker compose ). Да и конфиги лежат, совсем не рядом с сервисом, что добавляло неудобство их просмотров. В нашем случае конфиг сервер добавлял только ограничения в нашу архитектуру и не приносил удобств
Использование Spring Cloud Gateway в качестве OAuth2 клиента и KeyCloak для защиты служб