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, які выкарыстоўвае ўсталяваная праграма, перш чым адаптаваць код; не змешвайце гэтыя аб'екты ў гэтай канфігурацыі.

Падобныя артыкулы