Fake UserDetailsService if none is specified is unnecessary

[NadChel]

If I have a security application that doesn't actually perform any authentication and just parses an Authorization header for a JWT token (a separate service that issues them may, on the other hand, perform some authentication), I'm unlikly to actually register any AuthenticationManagers or UserDetailsServices. As a result, I will likely trigger all these conditionals and have a pointless UserDetailsService that matches against its in-memory map of one fake user in my context

@AutoConfiguration(before = ReactiveSecurityAutoConfiguration.class, after = RSocketMessagingAutoConfiguration.class)
@ConditionalOnClass({ ReactiveAuthenticationManager.class })
@ConditionalOnMissingClass({ "org.springframework.security.oauth2.client.registration.ClientRegistrationRepository",
		"org.springframework.security.oauth2.server.resource.introspection.ReactiveOpaqueTokenIntrospector" })
@ConditionalOnMissingBean(
		value = { ReactiveAuthenticationManager.class, ReactiveUserDetailsService.class,
				ReactiveAuthenticationManagerResolver.class },
		type = { "org.springframework.security.oauth2.jwt.ReactiveJwtDecoder" })
@Conditional(ReactiveUserDetailsServiceAutoConfiguration.ReactiveUserDetailsServiceCondition.class)
@EnableConfigurationProperties(SecurityProperties.class)
public class ReactiveUserDetailsServiceAutoConfiguration {

// SecurityProperties

	public static class User {

		/**
		 * Default user name.
		 */
		private String name = "user";

		/**
		 * Password for the default user name.
		 */
		private String password = UUID.randomUUID().toString();

Besides, it reflects on my console output (in case the password stays a random UUID, the config prints this info message):

INFO 4528 --- [dynamic-gateway] [           main] ctiveUserDetailsServiceAutoConfiguration : 

Using generated security password: 1d4b62fc-c703-4df9-a35f-8de5d5c7baab

It's not a tragedy since I don't inject it anywhere, but it feels wrong. I could register some stub AuthenticationManager to avoid a match, but it's a kludge. Frankly, I don't see any purpose in extending Spring's autoconfiguration magic to UserDetailsService. Even when you only start learning Spring Security, you can easily register some simple implementation, as you showed in your tutorial. In fact, it's even less straightforward for a beginner to go looking in their console output for the default password for their default user (which they may never suspect about)

[jzheaux]

If I have a security application that doesn't actually perform any authentication and just parses an Authorization header for a JWT token (a separate service that issues them may, on the other hand, perform some authentication), I'm unlikly to actually register any AuthenticationManagers or UserDetailsServices.

I'm not sure I agree with this, at least not as I've understood you so far.

I do not recommend simply parsing a token and not validating it (checking its signature, its expiry, etc.). It's important to validate the token you've received and not simply trust the client. In your case outlined above, I'd recommend you configure a ReactiveJwtDecoder which would remove the default UserDetailsService.

That said, if you have neither an AuthenticationManager, UserDetailsService, or any other Spring Security authentication mechanism, then you are correct that Spring Security will add a reasonable default in case any of its filters are used at runtime. We don't want Spring Security filters' OOTB configuration to allow for issuing an authentication result on no grounds at all.

However, if you want to remove that protection, you can disable the auto-configuration in the following way:

@SpringBootApplication(exclude=ReactiveUserDetailsServiceAutoConfiguration.class)

In fact, it's even less straightforward for a beginner to go looking in their console output for the default password for their default user (which they may never suspect about)

I think this is a fair point. Perhaps we should consider it as part of #14663 to further demystify the configuration choices Spring Security makes.

I'll close this for now. Please add more information as needed and we can continue chatting.

[NadChel]

I do not recommend simply parsing a token and not validating it (checking its signature, its expiry, etc.). It's important to validate the token you've received and not simply trust the client. In your case outlined above, I'd recommend you configure a ReactiveJwtDecoder which would remove the default UserDetailsService.

I'm not sure token validation counts as authentication. The parser I use (supplied by Jwts) automatically validates the claims and throws if the token is expired, not properly signed, etc. As I see it, extraction of claims and authentication of claims are two separate things (which, btw, should probably be performed by separate filters when authentication does occur in a given app)