JWKS-elŝutoj tra prokurilo por la reaktiva JWT-malĉifrilo de Spring

Enigu la klienton en NimbusReactiveJwtDecoder kaj konservu la ekzistantajn kontrolojn de eldoninto, aŭdantaro kaj aliaj ĵetonoj kiam vi konektas ĝin al la rimeda servilo.

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));

Uzu la fidatajn valorojn jwkSetUri/issuer kaj instaligu ĉi tiun malĉifrilon per la reala ReactiveJwtDecoder-fabo aŭ per eksplicita agordo de la rimeda servilo. Krei ĝin apud senŝanĝa aktiva malĉifrilo ne ŝanĝas la ŝlosilan ricevadon. Se la fidata JWKS-adreso estas publika kaj publikaj perantoj estas permesataj, la listo de HTTP-prokuriloj provizas kandidatojn por la gastiganto kaj pordo de la transporto sen konto.

La montrata validigilo konservas la defaŭltajn tempokontrolojn kaj la validigon de la eldoninto. Konservu la postulojn pri aŭdantaro kaj ĉiujn aldonajn validigilojn de la aplikaĵo kiam vi anstataŭigas la malĉifrilon.

Konata ŝlosila URI preterpasas la malkovron por lokalizi ĝin. Se alia komponanto ankoraŭ faras malkovron aŭ akiradon de ĵetonoj, agordu la itineron de tiu kliento aparte.

Ĉi tio kovras la reaktivan JWT-kontroladon en la rimeda servilo. La Servlet-rimeda servilo, la OAuth2-ensaluto kaj la klientoj de komercaj API-oj havas aliajn hokojn; konservu la malsukcesan ŝlosilan adreson kaj la etapon kun la esploro.

Rilataj artikoloj