Spring NimbusJwtDecoder: JWK सेट डाउनलोडलाई प्रोक्सी गर्नुहोस्

servlet डिकोडरलाई प्रोक्सी-सचेत RestTemplate दिनुहोस् र स्वचालित कन्फिगरेसन प्रतिस्थापन गर्दा issuer, audience र थप टोकन प्रमाणकहरू कायम राख्नुहोस्।

आउने 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 वा अन्य अनुप्रयोग जाँचको विकल्प होइन। स्वचालित रूपमा कन्फिगर गरिएको डिकोडर प्रतिस्थापन गर्दा ती कायम राख्नुहोस्; कुञ्जी-डाउनलोड मार्ग बदल्नाले अनुप्रयोगले कुन टोकन स्वीकार्नुपर्ने निर्धारण गर्दैन।

reactive डिकोडरले अर्को इन्टरफेस प्रयोग गर्छ। अन्य issuer-खोज वा टोकन-प्राप्ति क्लाइन्टहरूले पनि आफ्नै यातायात कन्फिगरेसन राख्छन्।

क्यास गरिएका कुञ्जीहरूले नयाँ डाउनलोड बिना प्रमाणीकरण सफल बनाउन सक्छन्। मार्ग मूल्याङ्कन गर्दा असफल कुञ्जी URL र रिफ्रेस वा इनिसियलाइजेसन चरण सुरक्षित राख्नुहोस्।

सम्बन्धित लेखहरू