org.springframework.boot.autoconfigure.security.servlet.UserDetailsServiceAutoConfiguration has a conditional on missing beans org.springframework.security.oauth2.client.registration.ClientRegistrationRepository (some OAuth2 clients are registered) and org.springframework.security.oauth2.server.resource.introspection.OpaqueTokenIntrospector (a resource server is configured). It is annoying that the default UserDetailsManager is disabled as soon as some OAuth2 clients are registered. I suppose it was assumed that an application registering clients would always use itself an OAuth2 authentication, but this is not always the case. For example, one might setup a simple HTTP Basic authentication with only one user (as with default auto-configuration), but this application may need to access a remote resource server with a OAuth2 client.
I suggest to simply remove the conditional on org.springframework.security.oauth2.client.registration.ClientRegistrationRepository.
Comment From: wilkinsona
Thanks for the suggestion. The current behaviour is intentional and we don't plan to change it. Please see this comment from @rwinch which explains the reasons for the behaviour and https://github.com/spring-projects/spring-boot/issues/24454 and https://github.com/spring-projects/spring-boot/issues/21503 for a few additional details.
Comment From: edouardhue
Hi @wilkinsona, @rwinch,
If I get it right, the idea was to skip the UserDetailsService when HttpSecurity#oauth2Client() is used, which seems perfectly correct. The problem is with the assumption that the UserDetailsService should be skipped whenever a ClientRegistrationRepository bean is present. It is true that the OAuth2ClientConfigurer will create a ClientRegistrationRepository in support to the authorization code grant filters, but my point is that this is not the only situation in which a ClientRegistrationRepository may be used. For example, using an AuthorizedClientServiceOAuth2AuthorizedClientManager and a WebClient with the client credentials grant has absolutely nothing to do with authenticating incoming requests, but still uses a ClientRegistrationRepository. It should not have the side effect of disabling the default UserDetailsService. I believe a more specific bean should be used in the condition, such as OAuth2AuthorizationRequestRedirectFilter or OAuth2AuthorizationCodeGrantFilter, which are created by OAuth2ClientConfigurer for the sole purpose of supporting the authorization code grant.
Comment From: wilkinsona
Unfortunately, this is a situation where we cannot please all of the people all of the time. Our preference is to err on the side not creating the user details service when it may be unnecessary. For cases where it was still wanted, you should define your own configured to meet your needs.