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.

Rilataj artikoloj