ბრაუზერი აღწევს იდენტობის მომწოდებელთან, შემდეგ შესვლა ვერ ხერხდება, როცა აპლიკაცია დაბრუნებულ ავტორიზაციის კოდს ცვლის. ეს გაცვლა აპლიკაციის სერვერიდან გამავალი მოთხოვნაა, საკუთარი HTTP კლიენტით.

Spring Security 6.5-ში ხელმისაწვდომი RestClient-ზე დაფუძნებული API-სთვის, ავტორიზაციის კოდის ტოკენის პასუხის კლიენტს მიაწოდეთ პროქსის გამცნობი მოთხოვნების ფაბრიკა:

SimpleClientHttpRequestFactory factory = new SimpleClientHttpRequestFactory();
factory.setProxy(new java.net.Proxy(
    java.net.Proxy.Type.HTTP,
    new java.net.InetSocketAddress("proxy.example", 8080)));
factory.setConnectTimeout(5000);
factory.setReadTimeout(15000);

RestClient tokenHttp = RestClient.builder()
    .requestFactory(factory)
    .messageConverters(converters -> {
        converters.clear();
        converters.add(new FormHttpMessageConverter());
        converters.add(new OAuth2AccessTokenResponseHttpMessageConverter());
    })
    .defaultStatusHandler(new OAuth2ErrorResponseErrorHandler())
    .build();

RestClientAuthorizationCodeTokenResponseClient tokenClient =
    new RestClientAuthorizationCodeTokenResponseClient();
tokenClient.setRestClient(tokenHttp);

გარდამქმნელისა და შეცდომების დამმუშავებლის კლასები ინარჩუნებენ Spring Security-ის დოკუმენტირებულ ტოკენის მოთხოვნის ქცევას. მხოლოდ დაუკავშირებელი JSON API-სთვის კონფიგურირებული ზოგადი RestClient ეკვივალენტური ჩანაცვლება არ არის.

დაუკავშირეთ იგივე tokenClient არსებულ უსაფრთხოების კონფიგურაციას:

http.oauth2Login(login -> login
    .tokenEndpoint(token -> token
        .accessTokenResponseClient(tokenClient)));

ეს კონფიგურაციის ფრაგმენტებია აპლიკაციისთვის, რომელსაც უკვე აქვს კლიენტის რეგისტრაცია და SecurityFilterChain. ისინი ირჩევენ აუთენტიფიკაციის გარეშე HTTP პროქსის; რწმუნებულების მოთხოვნისას საჭიროა არჩეული ტრანსპორტის შესაბამისი აუთენტიფიკაციის კონფიგურაცია. დაშვებულ საჯარო მარშრუტზე საჯაროდ ხელმისაწვდომი HTTPS ტოკენის ბოლო წერტილისთვის, HTTP პროქსების სიიდან HTTP ჩანაწერს შეუძლია შეავსოს ის ანგარიშის გარეშე პროქსის მისამართი.

პროქსის ჰოსტი გამოყავით მისი პორტისა და URL სქემისგან. დატოვეთ იდენტობის მომწოდებლის ტოკენის URI დანიშნულების ადგილად. მაგალითი არ ცვლის სერტიფიკატის ვალიდაციას.

შემდგომ მოთხოვნებს საკუთარი მფლობელობის შემოწმება სჭირდებათ. UserInfo-ის მიღება, განახლების ტოკენის გაცვლები, client-credentials გრანტები და დაცული API-ის გამოძახებები შეიძლება სხვა კლიენტის ობიექტებს იყენებდეს. დააკონფიგურირეთ შესაბამისი მხარდაჭერილი კლიენტი, როცა ამ ოპერაციასაც სჭირდება მარშრუტი. Spring Security 6.5-ის რეაქტიული client_credentials ნაკადისთვის, ცალკე დააკონფიგურირეთ რეაქტიული ტოკენის კლიენტი და მისი გრანტის მომწოდებელი.

OAuth2RestTemplate-ისა და AccessTokenProvider-ის გამოყენებით ძველი მაგალითები ეკუთვნის ძველ Spring Security OAuth პროექტს. კოდის ადაპტირებამდე აირჩიეთ API, რომელსაც დაინსტალირებული აპლიკაცია იყენებს; არ აურიოთ ეს ობიექტები ამ კონფიგურაციაში.

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