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. Для публічної адреси JWK на дозволеному маршруті публічного проксі список HTTP-проксі надає можливі значення хоста й порту.

Валідатор issuer у прикладі не замінює обов'язкові перевірки audience чи інші перевірки застосунку. Збережіть їх під час заміни автоматично налаштованого декодера; зміна маршруту завантаження ключа не визначає, які токени застосунок має приймати.

Реактивний декодер використовує інший інтерфейс. Інші клієнти виявлення issuer або отримання токенів також зберігають власну конфігурацію транспорту.

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

Схожі статті