Spring Security 6.5: Prokuri la OAuth-aŭtorigkodon-interŝanĝon
Donu al la responda kliento de la aŭtorigkoda ĵetono de Spring Security prokuran RestClient, konservante ĝiajn OAuth-konvertilojn kaj erarprilaborilon.
La retumilo atingas la identecprovizanton, poste la ensaluto malsukcesas kiam la aplikaĵo interŝanĝas la redonitan aŭtorigkodon. Tiu interŝanĝo estas elira peto de la aplikaĵservilo, kun propra HTTP-kliento.
Por la RestClient-bazita API disponebla en Spring Security 6.5, provizu prokuran petfabrikon al la responda kliento de la aŭtorigkoda ĵetono:
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);
La klasoj de konvertilo kaj erarprilaborilo konservas la dokumentitan konduton de ĵetonpetoj de Spring Security. Ĝenerala RestClient agordita nur por nerilata JSON-API ne estas ekvivalenta anstataŭaĵo.
Konektu la saman tokenClient al la ekzistanta sekurecagordo:
http.oauth2Login(login -> login
.tokenEndpoint(token -> token
.accessTokenResponseClient(tokenClient)));
Ĉi tiuj estas agordofragmentoj por aplikaĵo, kiu jam havas sian klientregistradon kaj SecurityFilterChain. Ili elektas HTTP-prokuron sen aŭtentikigo; prokuro postulanta akreditaĵojn bezonas la konforman aŭtentikagordon de la elektita transporto. Por publike atingebla HTTPS-ĵetonfina punkto sur permesita publika vojo, HTTP-enskribo el la HTTP-prokurlisto povas plenigi tiun prokuradreson sen konto.
Tenadu la prokuran gastiganton aparte de ĝia pordo kaj URL-skemo. Lasu la ĵetonan URI-on de la identecprovizanto kiel celon. La ekzemplo ne anstataŭas atestilan validigon.
Postaj petoj bezonas propran posedokontrolon. Akcepto de UserInfo, interŝanĝoj de refreŝiga ĵetono, donoj client-credentials kaj vokoj de protektita API povas uzi aliajn klientobjektojn. Agordu la konforman subtenatan klienton kiam tiu operacio ankaŭ bezonas la vojon. Por la reaktiva client_credentials-fluo de Spring Security 6.5, agordu la reaktivan ĵetonklienton kaj ĝian donprovizanton aparte.
Legacy-ekzemploj uzantaj OAuth2RestTemplate kaj AccessTokenProvider apartenas al la pli malnova projekto Spring Security OAuth. Elektu la API-on uzatan de la instalita aplikaĵo antaŭ ol adapti kodon; ne miksu tiujn objektojn en ĉi tiun agordon.