An incoming bearer request can reach the resource server while JWT verification fails on an outbound JWK download. Configure the HTTP client used by that decoder:

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

Use the application's real jwkSetUri and issuer, and install this decoder in the actual resource-server configuration. The example uses an unauthenticated HTTP proxy with the servlet-style Nimbus decoder. For a public JWK URL on a permitted public-proxy route, the HTTP proxy list provides candidate host and port values.

The issuer validator in the example is not a replacement for required audience or other application checks. Preserve those when replacing an automatically configured decoder; changing the key-download route does not define which tokens the app should accept.

A reactive decoder uses another interface. Other issuer-discovery or token-acquisition clients likewise keep their own transport configuration.

Cached keys can make validation succeed without a new download. Keep the failed key URL and refresh/initialization stage when evaluating the route.

ХӀокхунах тера йаззамаш