EnableAuthorizationServer creates multiple beans of the same type

[wilkinsona]

This was originally raised against Spring Boot, but the underlying problem is in Spring Security OAuth. Please see this Spring Boot issue for the details.

The summary is that multiple beans that implement ResourceServerTokenServices are registered with the application context. Depending on what other calls are made to the bean factory, one or both of those beans may be found. When both are found, neither is primary and a NoUniqueBeanDefinitionException is thrown.

This is the simplest reproduction that I'm aware of:

package com.example;

import org.springframework.context.annotation.AnnotationConfigApplicationContext;
import org.springframework.security.config.annotation.web.configuration.EnableWebSecurity;
import org.springframework.security.oauth2.config.annotation.web.configuration.AuthorizationServerConfigurerAdapter;
import org.springframework.security.oauth2.config.annotation.web.configuration.EnableAuthorizationServer;
import org.springframework.security.oauth2.provider.token.ResourceServerTokenServices;

@EnableAuthorizationServer
@EnableWebSecurity
public class BrokenOAuthApplication extends AuthorizationServerConfigurerAdapter {

	public static void main(String[] args) {
		AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext(BrokenOAuthApplication.class);
		context.getBean(ResourceServerTokenServices.class);
		context.close();
	}

}

This fails with Security OAuth 2.0.12.RELEASE, Security 4.2.1.RELEASE, and Framework 4.3.5.RELEASE.

[dsyer]

The above code fails because ResourceServerTokenServices is not available for autowiring without a qualifier. I don't think that's a bug reallly. It was designed that way (for better or for worse).

[wilkinsona]

That's not always the case, though. Here's another example that fails which isn't quite so simplified:

import org.springframework.context.ApplicationContext;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.Import;
import org.springframework.security.config.annotation.web.builders.HttpSecurity;
import org.springframework.security.config.annotation.web.configuration.EnableWebSecurity;
import org.springframework.security.config.annotation.web.configuration.WebSecurityConfigurerAdapter;
import org.springframework.security.oauth2.config.annotation.web.configuration.AuthorizationServerConfigurerAdapter;
import org.springframework.security.oauth2.config.annotation.web.configuration.EnableAuthorizationServer;
import org.springframework.security.oauth2.provider.token.ResourceServerTokenServices;
import org.springframework.stereotype.Component;

@Configuration
@Import({Security.class, Auth.class})
public class BrokenOAuthApplication {

	public static void main(String[] args) {
		AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext(BrokenOAuthApplication.class);
		context.getBean(ResourceServerTokenServices.class);
		context.close();
	}

}

@EnableWebSecurity
class Security extends WebSecurityConfigurerAdapter {

	private final ApplicationContext context;

	Security(ApplicationContext context) {
		this.context = context;
	}

	@Override
	protected void configure(HttpSecurity http) throws Exception {
		this.context.getBean(ResourceServerTokenServices.class);
	}

}

@EnableAuthorizationServer
class Auth extends AuthorizationServerConfigurerAdapter {

}

With this arrangement, the call to this.context.getBean(ResourceServerTokenServices.class) in Security succeeds but the one in the main method fails. If you swap the order of the two classes in the @Import then the call in Security fails.