En innkommende bearer-forespørsel kan nå ressursserveren mens JWT-verifiseringen feiler ved en utgående JWK-nedlasting. Konfigurer HTTP-klienten som dekoderen bruker:

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 applikasjonens ekte jwkSetUri og issuer, og installer denne dekoderen i den faktiske ressursserver-konfigurasjonen. Eksemplet bruker en uautentisert HTTP-proxy med Nimbus-dekoderen i servlet-stil. For en offentlig JWK-URL på en tillatt offentlig proxy-rute gir HTTP-proxy-listen kandidatverdier for vert og port.

Issuer-validatoren i eksemplet erstatter ikke påkrevde audience-kontroller eller andre applikasjonskontroller. Behold dem når en automatisk konfigurert dekoder erstattes; å endre nøkkel-nedlastingsruten definerer ikke hvilke tokens applikasjonen skal godta.

En reaktiv dekoder bruker et annet grensesnitt. Andre klienter for issuer-oppdagelse eller token-innhenting beholder også sin egen transportkonfigurasjon.

Hurtigbufrede nøkler kan gjøre verifiseringen vellykket uten en ny nedlasting. Behold URL-en til nøkkelen som feilet og oppdaterings- eller initialiseringsfasen når ruten vurderes.

Relaterte artikler