משאב WebClient שעובר דרך פרוקסי עדיין עלול להיכשל לפני קריאת ה-API אם השגת הטוקן משתמשת במחבר אחר. עבור זרימת client_credentials הריאקטיבית של Spring Security 6.5, חברו את שלושת החלקים:

HttpClient route = HttpClient.create()
    .proxy(p -> p.type(ProxyProvider.Proxy.HTTP)
        .host("proxy.example").port(8080));
WebClient tokenHttp = WebClient.builder()
    .clientConnector(new ReactorClientHttpConnector(route))
    .build();

var tokens = new WebClientReactiveClientCredentialsTokenResponseClient();
tokens.setWebClient(tokenHttp);

var provider = new ClientCredentialsReactiveOAuth2AuthorizedClientProvider();
provider.setAccessTokenResponseClient(tokens);

var manager = new AuthorizedClientServiceReactiveOAuth2AuthorizedClientManager(
    registrations, authorizedClients);
manager.setAuthorizedClientProvider(provider);

‏tokens.setWebClient מקצה את לקוח ה-HTTP של הטוקן; provider.setAccessTokenResponseClient מקצה אותו לספק ה-grant; manager.setAuthorizedClientProvider מתקין את אותו ספק. השתמשו במנהל הזה במסנן ה-OAuth בפועל או בזרימת העבודה של authorized-client.

‏HttpClient ו-ProxyProvider הם טיפוסים של Reactor Netty. ‏WebClient והמחבר שלו הם טיפוסים של Spring WebFlux. העבירו את ReactiveClientRegistrationRepository הקיים כ-registrations ואת ReactiveOAuth2AuthorizedClientService כ-authorizedClients.

הספק הזה מטפל ב-client_credentials; שמרו שרשרת ספקים מתאימה אם נדרשים grants אחרים. בדוגמה אין חשבון פרוקסי; הוא היה שייך לשכבת התעבורה ולא ל-OAuth client ID/secret. עבור token endpoint ציבורי המותר דרך מתווך ציבורי, בחרו host ו-port מרשימת פרוקסי HTTP.

הגדירו גם את המחבר של המשאב המוגן כאשר קריאות ה-API האלה זקוקות למסלול. הצלחת הטוקן והצלחת ה-API הן תוצאות נפרדות.

מאמרים קשורים