Spring Security 6.5: проксиране на обмена на код за оторизация OAuth

Дайте на клиента за отговор с токен за код за оторизация в Spring Security RestClient, съобразен с прокси, като запазите OAuth конверторите и обработчика на грешки.

Браузърът достига до доставчика на идентичност, след което входът се проваля, когато приложението обмени върнатия код за оторизация. Този обмен е изходяща заявка от сървъра на приложението, със собствен HTTP клиент.

За API-то, базирано на RestClient, налично в Spring Security 6.5, предоставете фабрика за заявки, съобразена с прокси, на клиента за отговор с токен за код за оторизация:

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. Обикновен RestClient, конфигуриран само за несвързано JSON API, не е равностойна замяна.

Свържете същия tokenClient със съществуващата конфигурация за сигурност:

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

Това са фрагменти от конфигурация за приложение, което вече има регистрация на клиент и SecurityFilterChain. Те избират HTTP прокси без удостоверяване; прокси, което изисква идентификационни данни, се нуждае от съответната конфигурация за удостоверяване на избрания транспорт. За публично достъпна крайна точка на HTTPS токен по разрешен публичен маршрут HTTP запис от списъка с HTTP проксита може да запълни този адрес на прокси без акаунт.

Дръжте хоста на проксито отделно от порта и URL схемата му. Оставете URI на токена на доставчика на идентичност като дестинация. Примерът не замества проверката на сертификата.

Следващите заявки се нуждаят от собствена проверка на собствеността. Извличането на UserInfo, обмените на токен за опресняване, предоставянията client-credentials и защитените API извиквания могат да използват други клиентски обекти. Конфигурирайте съответния поддържан клиент, когато тази операция също се нуждае от маршрута. За реактивния поток client_credentials на Spring Security 6.5 конфигурирайте реактивния клиент за токени и неговия доставчик на отстъпки отделно.

Старите примери с OAuth2RestTemplate и AccessTokenProvider принадлежат на по-стария проект Spring Security OAuth. Изберете API-то, което използва инсталираното приложение, преди да адаптирате код; не смесвайте тези обекти в тази конфигурация.

Подобни статии