Зачем нам нужна точно такая же конфигурация на сервере ресурсов и авторизации

Question

Я говорю о случае, когда эти два приложения являются отдельными.Я не заинтересован в объединении их в одном приложении.Итак, на сервере авторизации мы расширяем класс AuthorizationServerConfigurerAdapter, а на сервере ресурсов ResourceServerConfigurerAdapter, и в обоих мы создаем точно такие же бины, как JwtAccessTokenConverter, DefaultTokenServices и т. Д., Но в основном я не понимаю, зачем нам нужны TokenStore в обоих.

Значит ли это, что мы храним, например, в памяти один и тот же токен в разных приложениях?

Каков наилучший подход для удаления этого дублирования кода?Создать библиотеку для общих классов?Сделать запрос на авторизацию сервера для проверки токена?Но как нам извлечь дополнительную информацию из токена JWT, если у нас нет логики декодирования на сервере ресурсов?

Answer 1

Значит ли это, что мы храним, например, в памяти один и тот же токен в разных приложениях?

https://auth0.com/learn/json-web-tokens/

Это механизм аутентификации без сохранения состояниятак как пользовательское состояние никогда не сохраняется в памяти сервера.Защищенные маршруты сервера будут проверять допустимый JWT в заголовке авторизации, и, если он есть, пользователю будет разрешено.Поскольку JWT являются самодостаточными, имеется вся необходимая информация, что сокращает необходимость возврата к базе данных.

---

Каков наилучший подход для удаления этого дублирования кода?Создать библиотеку для общих классов?

Если вы используете симметричный ключ:

@Bean
    public JwtAccessTokenConverter accessTokenConverter() {
        JwtAccessTokenConverter converter = new JwtAccessTokenConverter();
        converter.setSigningKey("123");
        return converter;
    }

JwtAccessTokenConverter, DefaultTokenServices и т. Д. Будут идентичными компонентами как на сервере ресурсов, так и на сервере аутентификации, так что выможет иметь общий проект для обоих с объявлениями этих bean-компонентов и добавить их в качестве зависимости в обоих проектах.

Но, если вы используете асимметричную KeyPair, объявление bean-компонентов полностью меняется, и они не могут бытьто же самое.

Вы можете увидеть больше информации об этой разнице здесь:

https://www.baeldung.com/spring-security-oauth-jwt

---

Сделать запрос серверу авторизации для проверки токена?

Главное преимущество JWT не в том, чтобы делать это.

---

Но как мы собираемся извлечь дополнительную информацию из токена JWT, если у нас нетлогика декодирования на сервере ресурсов?

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

Answer 2

Лучший способ разрешить это дело в микросервисной системе - это создать несколько сущностей: API composer, сервис авторизации и бизнес-сервисы.

Базовый механизм этой схемы:

Во-первых, вы разделяете свои запросы неавторизованными и авторизуетесь с помощью заголовка токена.Обычно он называется что-то вроде "X-AUTHORIZATION-HEADER" или как-то так.В этом заголовке вы помещаете свой JWT-токен и отправляете его на шлюз сервера, роль которого выполняет 'API Composer' - это какой-то маршрутизатор, который принимает запросы и доставляет их соответствующим получателям,

В частности, API composer принимает ответ, анализирует заголовки, находит соответствующий заголовок с токеном и отправляет его в Auth Service и получает ответ с пользователемили ошибка.И в этой схеме вам нужны такие объекты, как JwtAccessTokenConverter, а только в Auth Service

Затем агрегированная полезная нагрузка ответа будет завершена, ваш API отправит ответ клиенту.

Я использую эту схему при разработке своих микросервисных систем, у меня она работает нормально.

Надеюсь, я правильно понял ваш вопрос и мой ответ вам поможет) С наилучшими пожеланиями.