សំណើ 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 ពិតរបស់កម្មវិធី ហើយដំឡើងឌីកូដ័រនេះក្នុងការកំណត់ម៉ាស៊ីនមេធនធានពិតប្រាកដ។ ឧទាហរណ៍ប្រើប្រូកស៊ី HTTP គ្មានការផ្ទៀងផ្ទាត់ជាមួយឌីកូដ័រ Nimbus បែប servlet។ សម្រាប់ URL JWK សាធារណៈនៅលើផ្លូវប្រូកស៊ីសាធារណៈដែលបានអនុញ្ញាត បញ្ជីប្រូកស៊ី HTTP ផ្តល់តម្លៃ host និង port ជាបេក្ខជន។

អ្នកផ្ទៀងផ្ទាត់ issuer ក្នុងឧទាហរណ៍មិនមែនជាការជំនួសការត្រួតពិនិត្យ audience ដែលត្រូវការ ឬការត្រួតពិនិត្យកម្មវិធីផ្សេងទៀតទេ។ រក្សាវានៅពេលជំនួសឌីកូដ័រដែលបានកំណត់ស្វ័យប្រវត្តិ។ ការផ្លាស់ប្តូរផ្លូវទាញយកកូនសោមិនកំណត់ថាតូកិនណាដែលកម្មវិធីគួរទទួលយកទេ។

ឌីកូដ័រ reactive ប្រើចំណុចប្រទាក់ផ្សេង។ អតិថិជនស្វែងរក issuer ឬទទួលតូកិនផ្សេងទៀតក៏រក្សាការកំណត់ការដឹកជញ្ជូនផ្ទាល់ខ្លួនដែរ។

កូនសោដែលបានឃ្លាំងសម្ងាត់អាចធ្វើឱ្យការផ្ទៀងផ្ទាត់ជោគជ័យដោយគ្មានការទាញយកថ្មី។ រក្សា URL កូនសោដែលបរាជ័យ និងដំណាក់កាលធ្វើឱ្យស្រស់ ឬចាប់ផ្តើម នៅពេលវាយតម្លៃផ្លូវ។

អត្ថបទពាក់ព័ន្ធ