Ein innkomande bearer-førespurnad kan nå ressursserveren medan JWT-verifiseringa feilar ved ei utgåande JWK-nedlasting. Konfigurer HTTP-klienten som dekodaren brukar:

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

Bruk dei ekte jwkSetUri og issuer til applikasjonen og installer denne dekodaren i den faktiske ressursserver-konfigurasjonen. Dømet brukar ein uautentisert HTTP-proxy med Nimbus-dekodaren i servlet-stil. For ein offentleg JWK-URL på ei tillaten offentleg proxy-rute gir HTTP-proxy-lista kandidatverdiar for vert og port.

Issuer-validatoren i dømet erstattar ikkje påkravde audience-kontrollar eller andre applikasjonskontrollar. Behald dei når ein automatisk konfigurert dekoder blir erstatta; å endre nøkkel-nedlastingsruta definerer ikkje kva token applikasjonen skal godta.

Ein reaktiv dekoder brukar eit anna grensesnitt. Andre klientar for issuer-oppdaging eller token-innhenting behald òg sin eigen transportkonfigurasjon.

Hurtiglagerde nøklar kan gjere verifiseringa vellukka utan ei ny nedlasting. Behald URL-en til nøkkelen som feila og oppdaterings- eller initialiseringsfasen når ruta blir vurdert.

Relaterte artiklar