Um pedido bearer de entrada pode chegar ao servidor de recursos enquanto a verificação JWT falha num download JWK de saída. Configure o cliente HTTP usado por esse 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 aplicação e instale este decodificador na configuração real do servidor de recursos. O exemplo usa um proxy HTTP não autenticado com o decodificador Nimbus no estilo servlet. Para um URL JWK público numa rota de proxy público permitida, a lista de proxies HTTP fornece valores candidatos de host e porta.

O validador de issuer do exemplo não substitui as verificações de audience obrigatórias nem outras verificações da aplicação. Preserve-as ao substituir um decodificador configurado automaticamente; alterar a rota de download da chave não define quais tokens a aplicação deve aceitar.

Um decodificador reativo usa outra interface. Outros clientes de descoberta de issuer ou de obtenção de tokens também mantêm a sua própria configuração de transporte.

Chaves em cache podem fazer a verificação ter sucesso sem um novo download. Guarde o URL da chave que falhou e a etapa de atualização ou inicialização ao avaliar a rota.

Artigos relacionados