Загрузка JWKS праз проксі для рэактыўнага JWT-дэкадара Spring

Укараніце кліент у NimbusReactiveJwtDecoder і захавайце існуючыя праверкі issuer, audience ды іншых токенаў пры падключэнні да сервера рэсурсаў.

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 або праз явную канфігурацыю сервера рэсурсаў. Стварэнне яго побач з нязменным актыўным дэкадарам не змяняе атрыманне ключоў. Калі давераны URL JWKS публічны і публічныя пасярэднікі дазволены, спіс HTTP-проксі прапануе варыянты для хаста і порта транспарту без уліковага запісу.

Паказаны валідатар захоўвае стандартныя праверкі часу і праверку issuer. Пры замене дэкадара захавайце патрабаванні да audience і ўсе дадатковыя валідатары праграмы.

Вядомы URI ключа абмінае выяўленне для яго пошуку. Калі іншы кампанент усё яшчэ выконвае выяўленне або атрыманне токена, наладзьце маршрут таго кліента асобна.

Гэта ахоплівае праверку рэактыўных JWT на серверы рэсурсаў. Servlet-сервер рэсурсаў, уваход праз OAuth2 і кліенты бізнес-API маюць іншыя кропкі падключэння; трымайце няўдалы URL ключа і этап разам з расследаваннем.

Падобныя артыкулы