@SteveRiesenberg many thanks for your reply.

I'm struggling to grasp the concept behind the implementation of the authorize method in the ClientCredentialsOAuth2AuthorizedClientProvider class. My concern is that for the client_credentials grant type, a refresh token should not be included (https://tools.ietf.org/html/rfc6749#section-4.4.3). Therefore, I don't understand why we check if the token is within a 60-second window of expiring, and then send a request to the authorization service to exchange the token ...?

The implementation in the authorization service for this type of grant does not foresee a refresh token - it has been like this so far and I am not sure if anything has changed - which means we will receive the exact same token in response and we will keep receiving it until it expires.

I am thinking of an implementation based on setting clockSkew to 0 seconds and additionally adding a retry mechanism in case of a 401 error.

OAuth2AuthorizedClientProvider authorizedClientProvider = OAuth2AuthorizedClientProviderBuilder.builder()
                .clientCredentials(
                        clientCredentialsGrantBuilder -> clientCredentialsGrantBuilder.clockSkew(Duration.ZERO))
                .build();

and retry mechanism:

public class WebClientRetryHelper {

    public static Retry retryUnauthorized() {
        return Retry.fixedDelay(1, Duration.ofMillis(500))
                .filter(throwable -> {
                    if (throwable instanceof WebClientResponseException ex) {
                        return ex.getStatusCode() == HttpStatus.UNAUTHORIZED;
                    }
                    return false;
                });
    }
}

1. What do you think about the above approach (with retry and clockSkew set to 0) - isn't it a bad way?

2. Could you explain the idea behind the implementation of authorize in the ClientCredentialsOAuth2AuthorizedClientProvider class, specifically based on the clock skew window?