Make it easier to create an integration test for an OAuth2 resource server

[dsyer]

If you want to integration test a resource server you need the OAuth2 client, but when you add that (even just in test scope) it changes the security configuration of a Spring Boot application by default - it is no longer a resource server, but instead it becomes an OAuth2 client (and installs an OAuth2 login filter instead of the resource server filter).

Also, it's kind of a pain to set up a RestClient with a bearer token for the test. You have to create an interceptor. With client credentials it looks like this:

@Bean
@Lazy
public RestClient personService(RestClient.Builder builder, ClientRegistrationRepository repository,
		OAuth2AuthorizedClientService service,
		@Value("http://localhost:${local.server.port:8080}") String url) {
	AuthorizedClientServiceOAuth2AuthorizedClientManager manager = new AuthorizedClientServiceOAuth2AuthorizedClientManager(
			repository, service);
	OAuth2ClientHttpRequestInterceptor interceptor = new OAuth2ClientHttpRequestInterceptor(manager);
	interceptor.setClientRegistrationIdResolver(request -> "spring");
	builder.baseUrl(url).requestInterceptor(interceptor);
	return builder.build();
}

Ideally we'd like a way to tell Spring Boot that to set that stuff up: 1) switch off the OAuth2SecurityFilterChainConfiguration (currently not visible and not an independent autoconfig, so you can't actually exclude it); 2) make it easier to create an HTTP client.

Sort of related to #43978 but this is for a webapp that is itself a resource server.

[wilkinsona]

switch off the OAuth2SecurityFilterChainConfiguration (currently not visible and not an independent autoconfig, so you can't actually exclude it)

Do you lose too much if you exclude org.springframework.boot.autoconfigure.security.oauth2.client.servlet.OAuth2ClientAutoConfiguration?

make it easier to create an HTTP client

Isn't that a job for Spring Security? I don't see anything Boot-specific about the boilerplate above.

[dsyer]

Excluding the OAuth2ClientAutoconfiguration leads to other issues because I still have a client.

Caused by: org.springframework.beans.factory.NoSuchBeanDefinitionException: No qualifying bean of type 'org.springframework.security.oauth2.client.registration.ClientRegistrationRepository' available: expected at least 1 bean which qualifies as autowire candidate. Dependency annotations: {}

OAuth2ClientAutoconfiguration is an @Import of 2 separate classes and I guess I need one of them.

Actually, having tried it, it turns out I need parts of both for my RestClient to work as above:

		@Bean
		@ConditionalOnMissingBean(ClientRegistrationRepository.class)
		InMemoryClientRegistrationRepository clientRegistrationRepository(OAuth2ClientProperties properties) {
			List<ClientRegistration> registrations = new ArrayList<>(
					new OAuth2ClientPropertiesMapper(properties).asClientRegistrations().values());
			return new InMemoryClientRegistrationRepository(registrations);
		}

		@Bean
		@ConditionalOnMissingBean
		OAuth2AuthorizedClientService authorizedClientService(
				ClientRegistrationRepository clientRegistrationRepository) {
			return new InMemoryOAuth2AuthorizedClientService(clientRegistrationRepository);
		}

[wilkinsona]

It looks like we're suffering a bit as the class path's a poor signal for what you want due to Spring Security having its client-side OAuth2 client support and its server-side OAuth2 client support in the same jar. That means we need a better signal or to at least split things up a bit so that you can use excludes to manually get what you want.

We auto-configure 4 beans:

• InMemoryClientRegistrationRepository
• OAuth2AuthorizedClientService
• OAuth2AuthorizedClientRepository
• SecurityFilterChain

InMemoryClientRegistrationRepository and OAuth2AuthorizedClientService are used on both sides while OAuth2AuthorizedClientRepository and SecurityFilterChain are server-specific. I think we need to restructure the auto-configuration to reflect this. Maybe OAuth2ClientAutoConfiguration for the pieces that are used on both sides and OAuth2ClientWebAutoConfiguration (not sure about this name) for the server-specific pieces.

We also have the same problem on the reactive side with ReactiveOAuth2ClientAutoConfiguration.

When we split things up, we should think about the package names too.

OAuth2ClientAutoConfiguration is in org.springframework.boot.autoconfigure.security.oauth2.client.servlet at the moment. That package might make sense for OAuth2ClientWebAutoConfiguration but there's nothing servlet-specific about InMemoryClientRegistrationRepository and OAuth2AuthorizedClientService so it won't really make sense for the revised OAuth2ClientAutoConfiguration.

On the reactive side, ReactiveOAuth2ClientAutoConfiguration is in org.springframework.boot.autoconfigure.security.oauth2.client.reactive which isn't as bad as it doesn't imply web application in the same way that servlet does.

There's quite a bit of overlap with #40997.