Unha solicitude bearer entrante pode chegar ao servidor de recursos mentres a verificación JWT falla nunha descarga JWK saínte. Configure o cliente HTTP que usa ese decodificador:

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 os jwkSetUri e issuer reais da aplicación e instale este decodificador na configuración real do servidor de recursos. O exemplo usa un proxy HTTP non autenticado co decodificador Nimbus de estilo servlet. Para un URL JWK público nunha ruta de proxy público permitida, a lista de proxies HTTP ofrece valores candidatos de host e porto.

O validador de issuer do exemplo non substitúe as comprobacións de audiencia obrigatorias nin outras comprobacións da aplicación. Consérveas ao substituír un decodificador configurado automaticamente; cambiar a ruta de descarga de claves non define que tokens debe aceptar a aplicación.

Un decodificador reactivo usa outra interface. Outros clientes de descubrimento de issuer ou de obtención de tokens tamén manteñen a súa propia configuración de transporte.

As claves na caché poden facer que a verificación teña éxito sen unha nova descarga. Conserve o URL da clave fallida e a etapa de actualización ou inicialización ao avaliar a ruta.

Artigos relacionados