Spring NimbusJwtDecoder: pośredniczenie w pobieraniu zestawu JWK

Przekaż dekoderowi servlet RestTemplate świadomy proxy i zachowaj walidatory issuer, audience oraz dodatkowe walidatory tokenów przy zastępowaniu automatycznej konfiguracji.

Przychodzące żądanie bearer może dotrzeć do serwera zasobów, podczas gdy weryfikacja JWT kończy się niepowodzeniem przy wychodzącym pobieraniu JWK. Skonfiguruj klienta HTTP używany przez ten dekoder:

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

Użyj rzeczywistych jwkSetUri i issuer aplikacji i zainstaluj ten dekoder w rzeczywistej konfiguracji serwera zasobów. Przykład używa nieuwierzytelnionego proxy HTTP z dekoderem Nimbus w stylu servlet. Dla publicznego URL JWK na dozwolonej trasie publicznego proxy lista proxy HTTP podaje kandydatów na wartości hosta i portu.

Walidator issuer w przykładzie nie zastępuje wymaganych kontroli audience ani innych kontroli aplikacji. Zachowaj je przy zastępowaniu automatycznie skonfigurowanego dekodera; zmiana trasy pobierania klucza nie określa, jakie tokeny aplikacja powinna akceptować.

Dekoder reaktywny używa innego interfejsu. Inni klienci wykrywania issuer lub pozyskiwania tokenów również zachowują własną konfigurację transportu.

Klucze w pamięci podręcznej mogą sprawić, że weryfikacja się powiedzie bez nowego pobierania. Podczas oceny trasy zachowaj URL nieudanego klucza oraz etap odświeżania lub inicjalizacji.

Powiązane artykuły