How to handle OAuth2 access token refresh with synchronous API calls, in Spring Security 5

We are using Spring Gateway (Spring Boot 2.4.6) which uses Spring Security 5 and the Weblux/ reactive model within that to provide OAuth2 security and Keycloak as the IDP.

Refreshing of the Access Token is an issue when our front-end application, which has already [successfully] authenticated against the gateway/ IDP, issues multiple API calls after the session's access token has expired. It appears that out of (for example) five API calls, only the last one gets re-authenticated against the Keycloak provider and the other four get 'lost', thereby causing issues within the front-end.

If the user refreshes the UI's page then the proper authentication flow happens seamlessly and the token stored in the session is refreshed, without a redirect to the Keycloak login screen (as expected), therefore the problem is only with synchronous API calls.

The SecurityWebFilterChain is setup with:

 /*
 * Enable oauth2 authentication on all requests, but use our custom
 * RegistrationRepository
 */
    .and()
    .oauth2Login()
    .authenticationSuccessHandler(new AuthSuccessHandler(requestCache)) // handle success login
    .authenticationFailureHandler((exchange, excep) -> {
        LOGGER.debug("Authentication failure: {}", excep.getMessage());
        return Mono.empty();
})

.clientRegistrationRepository(clientReg);

// Add our custom filter to the security chain
final KeycloakClientLoginFilter keyclockLogin = new KeycloakClientLoginFilter(
        clientReg,
        redirectStrategy,
        requestCache,
        authClientService);
clientReg.setKeycloakClientLoginFilter(keyclockLogin);

http.addFilterBefore(keyclockLogin, SecurityWebFiltersOrder.LOGIN_PAGE_GENERATING);
return http.build();

With the ServerAuthenticationSuccessHandler configured with this:

private class AuthSuccessHandler implements ServerAuthenticationSuccessHandler {
        private final ServerRequestCache requestCache;
        private final URI defaultLocation = URI.create("/login");

    private AuthSuccessHandler(ServerRequestCache requestCache) {
        this.requestCache = requestCache;
    }

    @Override
    public Mono<Void> onAuthenticationSuccess(WebFilterExchange webFilterExchange, Authentication authentication) {
        final ServerWebExchange exchange = webFilterExchange.getExchange();
        return requestCache.getRedirectUri(exchange)
                .defaultIfEmpty(defaultLocation)
                .flatMap(location -> {
                    LOGGER.debug("Authentication success. Redirecting request to {}", location.toASCIIString());
                    return redirectStrategy.sendRedirect(exchange, location);
                });
    }
}

Within the KeycloakClientLoginFilter there is a ServerWebExchangeMatcher that checks if the required details are present on the inbound exchange, and whether the AccessToken has (or is about to) expire. If it is, it runs through this code to redirect the request off to Keycloak for authentication and/ or refresh:

final ClientRegistration keycloakReg = clientReg.getRegistration(tenantId, appId);

if (!isError && loginRedirects.containsKey(keycloakReg.getRegistrationId())) {
    final String contextPath = exchange.getRequest().getPath().contextPath().value();
    final URI redirect = URI.create(contextPath + loginRedirects.get(keycloakReg.getRegistrationId()));
    if (LOGGER.isDebugEnabled()) {
        LOGGER.debug("About to redirect to keycloak; for method {}, tenant={}",
                exchange.getRequest().getMethod(),
                tenantId);
    }
    // Save the request so the URL can be retreived on successful login
    return requestCache.saveRequest(exchange)
            .then(redirectStrategy.sendRedirect(exchange, redirect));
}

So, all API calls hit the above code, require a refresh, have their original exchanges saved in the requestCache and are then directed to Keycloak. When Keycloak responds with the updated token, the exchange(s) run through the AuthSuccessHandler, which pulls the original request URL from the requestCache and redirects the call to that original URL. This part works for web requests and the one in five API calls.

The other four API calls never make it to the AuthSuccessHandler - They simply get 'lost'. There are some ugly hacks that could be done, like blocking all calls until the one first one is re-authenticated, but that just isn't right and would be hard to get right anyway.

So can the gateway, CookieServerRequestCache or AuthenticationWebFilter only handle one request at a time? Is there a 'simple' implementation of waiting on one call from the same session to re-authenticate? Any help would be greatly appreciated as the application simply doesn't work (from a user's perspective) until this is resolved.