შემომავალი 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 პროქსის servlet სტილის Nimbus დეკოდერთან. დაშვებულ საჯარო პროქსის მარშრუტზე საჯარო JWK URL-ისთვის HTTP პროქსების სია გთავაზობთ ჰოსტისა და პორტის კანდიდატურ მნიშვნელობებს.

მაგალითში issuer ვალიდატორი არ ცვლის სავალდებულო audience ან აპლიკაციის სხვა შემოწმებებს. შეინარჩუნეთ ისინი ავტომატურად კონფიგურირებული დეკოდერის ჩანაცვლებისას; გასაღების ჩამოტვირთვის მარშრუტის შეცვლა არ განსაზღვრავს, რომელი token-ები უნდა მიიღოს აპლიკაციამ.

რეაქტიული დეკოდერი სხვა ინტერფეისს იყენებს. issuer-ის აღმოჩენის ან token-ის მოპოვების სხვა კლიენტებიც ინარჩუნებენ საკუთარ ტრანსპორტის კონფიგურაციას.

ქეშირებულმა გასაღებებმა შეიძლება შემოწმება წარმატებული გახადოს ახალი ჩამოტვირთვის გარეშე. მარშრუტის შეფასებისას შეინარჩუნეთ წარუმატებელი გასაღების URL და განახლების ან ინიციალიზაციის ეტაპი.

დაკავშირებული სტატიები