Завантаження JWKS через проксі для реактивного JWT-декодера Spring

Впровадьте клієнт у NimbusReactiveJwtDecoder і збережіть наявні перевірки видавця, аудиторії та інших токенів під час підключення до сервера ресурсів.

var transport = reactor.netty.http.client.HttpClient.create()
    .proxy(spec -> spec
        .type(reactor.netty.transport.ProxyProvider.Proxy.HTTP)
        .host("proxy.example")
        .port(8080));
var webClient = org.springframework.web.reactive.function.client.WebClient
    .builder()
    .clientConnector(new org.springframework.http.client.reactive
        .ReactorClientHttpConnector(transport))
    .build();

var decoder = org.springframework.security.oauth2.jwt.NimbusReactiveJwtDecoder
    .withJwkSetUri(jwkSetUri)
    .webClient(webClient)
    .build();
decoder.setJwtValidator(org.springframework.security.oauth2.jwt.JwtValidators
    .createDefaultWithIssuer(issuer));

Використовуйте довірені значення jwkSetUri/issuer і встановіть цей декодер через реальний бін ReactiveJwtDecoder або явну конфігурацію сервера ресурсів. Створення його поруч із незміненим активним декодером не змінює отримання ключів. Якщо довірена адреса JWKS є публічною і публічні посередники дозволені, список HTTP-проксі пропонує кандидатів для хоста й порту транспорту без облікового запису.

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

Відомий URI ключа обходить виявлення для його пошуку. Якщо інший компонент досі виконує виявлення або отримання токенів, налаштуйте маршрут того клієнта окремо.

Це охоплює перевірку реактивних JWT на сервері ресурсів. Servlet-сервер ресурсів, вхід через OAuth2 і клієнти бізнес-API мають інші точки підключення; збережіть невдалу адресу ключа та етап разом із розслідуванням.

Схожі статті