Spring Authorization Server fails to start with multiple PasswordEncoder beans

[Dayde]

Describe the bug
When having multiple PasswordEncoder declared as beans, Spring Authorization Server ignores the @Primary hint and fails to start because it finds multiple beans.

This behaviour is present since the beginning of the project. We’re using 0.4.5 but the reproducer joined below demonstrates the same problem with version 1.2.4.

To Reproduce
Declare multiple PasswordEncorder as components with one as @Primary

    @Bean
    fun bcryptPasswordEncoder(): PasswordEncoder {
        return BCryptPasswordEncoder()
    }

    @Bean
    @Primary
    fun delegatingPasswordEncoder(): PasswordEncoder {
        return PasswordEncoderFactories.createDelegatingPasswordEncoder()
    }

Expected behavior
The component declared as @Primary should be used.

Sample
Reproducer available here -> https://gitlab.com/maltcommunity/public/oss/spring-authorization-server-bug-reproducer/

[Dayde]

The problem arises at that point ->

spring-authorization-server/oauth2-authorization-server/src/main/java/org/springframework/security/oauth2/server/authorization/config/annotation/web/configurers/OAuth2ClientAuthenticationConfigurer.java

Line 243 in 6eda8c6

PasswordEncoder passwordEncoder = OAuth2ConfigurerUtils.getOptionalBean(httpSecurity, PasswordEncoder.class);

Because the getOptionalBean method does not rely on a simple getBean but on beansOfTypeIncludingAncestors https://github.com/spring-projects/spring-authorization-server/blob/main/oauth2-authorization-server/src/main/java/org/springframework/security/oauth2/server/authorization/config/annotation/web/configurers/OAuth2ConfigurerUtils.java#L208

[jgrandja]

@Dayde

When having multiple PasswordEncoder declared as beans, Spring Authorization Server ignores the @Primary hint and fails to start because it finds multiple beans.

Can you please provide details on why you need to define multiple PasswordEncoder @Beans? Please provide each component that requires a PasswordEncoder (ClientSecretAuthenticationProvider being one of them)

[spring-projects-issues]

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

[spring-projects-issues]

Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.

[Dayde]

Hi, sorry for the late answer.

We have multiple implementations of DaoAuthenticationProvider in our codebase for different authentication mechanisms which historically had different password encoders.

[Dayde]

To be honest, "Why would one need different PasswordEncoder?" does not seem like a legitimate question to me. Having to migrate a user based from one encryption to another without downtime, having different kinds of authentication mechanism relying on different encryptions, even demonstrating the result of different password encoders for the sake of it, I’m pretty sure I’m missing a ton of legitimate use cases for wanting to register multiple PasswordEncoder as Bean.

Legitimate or not, the error being logged is misleading since the code ignores the @Primary used to indicate which implementation to use.

As you can see when you run the reproducer:

***************************
APPLICATION FAILED TO START
***************************

Description:

Method authorizationServerSecurityFilterChain in com.malt.reproducer.SecurityConfig required a single bean, but 2 were found:
        - bcryptPasswordEncoder: defined by method 'bcryptPasswordEncoder' in class path resource [com/malt/reproducer/MultiplePasswordEncodersConfiguration.class]
        - delegatingPasswordEncoder: defined by method 'delegatingPasswordEncoder' in class path resource [com/malt/reproducer/MultiplePasswordEncodersConfiguration.class]

This may be due to missing parameter name information

Action:

Consider marking one of the beans as @Primary, updating the consumer to accept multiple beans, or using @Qualifier to identify the bean that should be consumed

[jgrandja]

@Dayde

To be honest, "Why would one need different PasswordEncoder?" does not seem like a legitimate question to me.

I ask questions to understand your use case in more detail so I can better help. All questions are legitimate IMO.

the error being logged is misleading since the code ignores the @Primary used to indicate which implementation to use.

Ignoring @Primary is intentional. Spring Authorization cannot assume a @Primary PasswordEncoder @Bean is intended to be used for client credentials matching.

FYI, DaoAuthenticationProvider is intended to be used for user credentials (UserDetails) matching.

If you have multiple PasswordEncoder @Bean's then you need to explicitly set it via ClientSecretAuthenticationProvider.setPasswordEncoder().