Saapuva bearer-pyyntö voi saavuttaa resurssipalvelimen, vaikka JWT-vahvistus epäonnistuu lähtevässä JWK-latauksessa. Määritä HTTP-asiakas, jota kyseinen dekooderi käyttää:

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

Käytä sovelluksen todellisia jwkSetUri ja issuer-arvoja ja asenna tämä dekooderi todelliseen resurssipalvelimen kokoonpanoon. Esimerkki käyttää autentikoimatonta HTTP-välityspalvelinta servlet-tyylisellä Nimbus-dekooderilla. Julkiselle JWK-URL-osoitteelle sallitulla julkisen välityspalvelimen reitillä HTTP-välityspalvelinluettelo tarjoaa mahdolliset isäntä- ja porttiarvot.

Esimerkin issuer-validoija ei korvaa vaadittuja audience-tarkistuksia tai muita sovelluksen tarkistuksia. Säilytä ne, kun korvaat automaattisesti määritetyn dekooderin; avaimen latausreitin muuttaminen ei määritä, mitkä tokenit sovelluksen tulee hyväksyä.

Reaktiivinen dekooderi käyttää toista rajapintaa. Myös muut issuer-tunnistuksen tai tokenien hankinnan asiakkaat säilyttävät oman siirtokokoonpanonsa.

Välimuistiin tallennetut avaimet voivat saada vahvistuksen onnistumaan ilman uutta latausta. Säilytä epäonnistuneen avaimen URL ja päivitys- tai alustusvaihe reittiä arvioidessasi.

Aiheeseen liittyvät artikkelit