En inkommande bearer-förfrågan kan nå resursservern medan JWT-verifieringen misslyckas vid en utgående JWK-nedladdning. Konfigurera HTTP-klienten som dekodaren använder:

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

Använd applikationens riktiga jwkSetUri och issuer och installera denna dekoder i den faktiska resursserver-konfigurationen. Exemplet använder en oautentiserad HTTP-proxy med Nimbus-dekodern i servlet-stil. För en offentlig JWK-URL på en tillåten offentlig proxy-rutt ger HTTP-proxylistan möjliga värden för värd och port.

Issuer-valideraren i exemplet ersätter inte obligatoriska audience-kontroller eller andra applikationskontroller. Behåll dem när en automatiskt konfigurerad dekoder ersätts; att ändra nyckelns nedladdningsrutt avgör inte vilka tokens applikationen ska acceptera.

En reaktiv dekoder använder ett annat gränssnitt. Andra klienter för issuer-upptäckt eller tokenanskaffning behåller också sin egen transportkonfiguration.

Cachelagrade nycklar kan göra verifieringen lyckad utan en ny nedladdning. Behåll URL:en för den misslyckade nyckeln och uppdaterings- eller initieringsfasen när rutten utvärderas.

Relaterade artiklar