How to use automatic renewal of access tokens in a clustered environment?

I have successfully run a single instance of Spring Authorization Server alongside individual instances of the client and resource servers. The automatic renewal of access tokens functions properly in this setup.

However, when attempting to deploy the authorization server in a clustered environment, the access token renewal feature no longer works as expected.

I actually simulated a clustered environment using docker compose with Nginx as proxy and two instances of Spring Authorization Server.

Upon debugging the client application, I observed that the getResponse method of DefaultRefreshTokenTokenResponseClient is making a call to http://localhost:9000/oauth2/token. However, the authorization server responds with a redirect to http://localhost:9000/login, causing the getTokenResponse method to throw a NullPointerException.

The specific error message is as follows:
> Cannot invoke "org.springframework.security.oauth2.core.endpoint.OAuth2AccessTokenResponse.getAccessToken()" because "tokenResponse" is null.

In the authorization server configuration, I've incorporated Spring Session to manage sessions and implemented a key rotation strategy inspired by Rob Winch's implementation. Both these components store data in a database.

Even if I configure the client to use HttpSessionOAuth2AuthorizedClientRepository, it seems that Spring Session is unable to act as a proxy in front of it. I can see the org.springframework.security.oauth2.client.web.HttpSessionOAuth2AuthorizedClientRepository.AUTHORIZED_CLIENTS in SPRING_SESSION_ATTRIBUTES, but the client application fails.

@Bean
public OAuth2AuthorizedClientRepository authorizedClientRepository() {
	return new HttpSessionOAuth2AuthorizedClientRepository();
}

I was able to resolve this issue by configuring stick sessions in the proxy.

http {
  upstream loadbalancer {
    ip_hash;  ## Sticky session
    server authz1:9000;
    server authz2:9000;
  }

However, I initially anticipated that Spring Session could address this concern as well. Now, I'm uncertain whether I've made a mistake in my setup, or if Spring Authorization Server and Spring Session are simply not suited to handle this particular configuration. Should I consider abandoning Spring Session in favor of a stick session configuration, or is there a solution that I might be overlooking?

You can configure JdbcOAuth2AuthorizationService as in the official sample to persist authorizations to a database. If a relational database does not work for you, you can build your own OAuth2AuthorizationService for your chosen data store.

By persisting authorizations in a database, the refresh_token can be used to refresh the access_token no matter which instance in the cluster is chosen to service the request.