Spring NimbusJwtDecoder: проксирование загрузки набора JWK

Передайте сервлетному декодеру RestTemplate, учитывающий прокси, и сохраните валидаторы issuer, audience и дополнительные валидаторы токенов при замене автоконфигурации.

Входящий bearer-запрос может дойти до сервера ресурсов, тогда как проверка JWT завершается ошибкой при исходящей загрузке JWK. Настройте HTTP-клиент, который использует этот декодер:

var factory = new org.springframework.http.client.SimpleClientHttpRequestFactory();
factory.setProxy(new java.net.Proxy(
    java.net.Proxy.Type.HTTP,
    new java.net.InetSocketAddress("proxy.example", 8080)));
var rest = new org.springframework.web.client.RestTemplate(factory);

var decoder = org.springframework.security.oauth2.jwt.NimbusJwtDecoder
    .withJwkSetUri(jwkSetUri)
    .restOperations(rest)
    .build();
decoder.setJwtValidator(
    org.springframework.security.oauth2.jwt.JwtValidators
        .createDefaultWithIssuer(issuer));

Используйте реальные jwkSetUri и issuer приложения и установите этот декодер в фактическую конфигурацию сервера ресурсов. В примере используется неаутентифицированный HTTP-прокси с декодером Nimbus в стиле servlet. Для публичного URL JWK на разрешённом маршруте публичного прокси список HTTP-прокси предоставляет возможные значения хоста и порта.

Валидатор issuer в примере не заменяет обязательные проверки audience или другие проверки приложения. Сохраните их при замене автоматически настроенного декодера; изменение маршрута загрузки ключа не определяет, какие токены приложение должно принимать.

Реактивный декодер использует другой интерфейс. Другие клиенты обнаружения issuer или получения токенов также сохраняют собственную конфигурацию транспорта.

Кэшированные ключи могут обеспечить успешную проверку без новой загрузки. При оценке маршрута сохраняйте URL неудачного ключа и этап обновления или инициализации.

Похожие статьи