Spring NimbusJwtDecoder: JWK संच डाउनलोड प्रॉक्सी करा

येणारी bearer विनंती रिसोर्स सर्व्हरपर्यंत पोहोचू शकते, पण JWT पडताळणी बाहेर जाणाऱ्या JWK डाउनलोडवर अयशस्वी होते. त्या डिकोडरने वापरलेला HTTP क्लायंट कॉन्फिगर करा:

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

अ‍ॅप्लिकेशनचे खरे jwkSetUri आणि issuer वापरा आणि हा डिकोडर खऱ्या रिसोर्स-सर्व्हर कॉन्फिगरेशनमध्ये बसवा. उदाहरण servlet शैलीतील Nimbus डिकोडरसह प्रमाणीकरण नसलेला HTTP प्रॉक्सी वापरते. परवानगी असलेल्या सार्वजनिक-प्रॉक्सी मार्गावरील सार्वजनिक JWK URL साठी HTTP प्रॉक्सी सूची संभाव्य host आणि port मूल्ये देते.

उदाहरणातील issuer व्हॅलिडेटर आवश्यक audience किंवा इतर अ‍ॅप्लिकेशन तपासण्यांचा पर्याय नाही. स्वयंचलितपणे कॉन्फिगर केलेला डिकोडर बदलताना त्या जपून ठेवा; की-डाउनलोड मार्ग बदलल्याने अ‍ॅप्लिकेशनने कोणते टोकन स्वीकारावेत हे ठरत नाही.

रिॲक्टिव्ह डिकोडर दुसरे इंटरफेस वापरतो. issuer शोध किंवा टोकन मिळवणी करणारे इतर क्लायंटही त्यांचे स्वतःचे वाहतूक कॉन्फिगरेशन ठेवतात.

कॅशेमधील की नवीन डाउनलोडशिवाय पडताळणी यशस्वी करू शकतात. मार्गाचे मूल्यांकन करताना अयशस्वी की URL आणि रिफ्रेश किंवा इनिशियलायझेशन टप्पा जपून ठेवा.