What is ReactiveUserDetailsService, how does it fit into WebFlux authentication, and how do you provide one?

## The abstraction `ReactiveUserDetailsService` is a functional interface: ```java public interface ReactiveUserDetailsService { Mono<UserDetails> findByUsername(String username); } ``` It is the reactive twin of the servlet `UserDetailsService` (`UserDetails loadUserByUsername(String)`). Returning **`Mono<UserDetails>`** lets the lookup be asynchronous/non-blocking (R2DBC, reactive Mongo, a remote call) so it never ties up a Netty event-loop thread. **`UserDetails`** describes the user: `getUsername()`, `getPassword()` (the **encoded** password), `getAuthorities()`, and status flags (`isEnabled`, `isAccountNonLocked`, `isAccountNonExpired`, `isCredentialsNonExpired`). ## How it plugs into authentication For username/password mechanisms (HTTP Basic, form login), authentication is coordinated by a `ReactiveAuthenticationManager`. The out-of-the-box implementation is **`UserDetailsRepositoryReactiveAuthenticationManager`**, which: 1. calls `findByUsername(username)`, 2. if `Mono.empty()`, raises `UsernameNotFoundException` (surfaced as bad credentials to avoid user enumeration), 3. otherwise checks the presented raw password against `userDetails.getPassword()` using the configured **`PasswordEncoder`**, 4. validates the status flags, 5. emits a fully-authenticated `Authentication` (an `UsernamePasswordAuthenticationToken` with authorities). With Spring Boot, **simply defining a `ReactiveUserDetailsService` bean plus a `PasswordEncoder` bean** is enough — Boot's reactive security auto-config builds that manager and wires it in. You usually don't construct the manager yourself. ## In-memory implementation ```java @Bean ReactiveUserDetailsService users(PasswordEncoder encoder) { UserDetails u = User.withUsername("alice") .password(encoder.encode("secret")) .roles("USER") .build(); return new MapReactiveUserDetailsService(u); } @Bean PasswordEncoder encoder() { return PasswordEncoderFactories.createDelegatingPasswordEncoder(); } ``` `MapReactiveUserDetailsService` is the reactive analogue of `InMemoryUserDetailsManager` — great for tests/demos, not production. ## Database-backed implementation ```java @Bean ReactiveUserDetailsService userDetailsService(UserR2dbcRepository repo) { return username -> repo.findByUsername(username) .map(u -> User.withUsername(u.getUsername()) .password(u.getPasswordHash()) .authorities(u.getRoles().toArray(String[]::new)) .build()); } ``` Returning `Mono.empty()` when the row is missing is important — the manager translates it into an authentication failure. Never `.block()` inside the lambda. ## Relationship to ReactiveAuthenticationManager `ReactiveUserDetailsService` is **not** itself an authentication manager — it only *loads* users. The `ReactiveAuthenticationManager` (specifically `UserDetailsRepositoryReactiveAuthenticationManager`) *uses* it to *authenticate*. If you set a custom `authenticationManager` on `ServerHttpSecurity`/the auth filter, your user-details bean may be bypassed unless that manager consults it. ## Gotchas - Forgetting the `PasswordEncoder` bean -> startup/`IllegalArgumentException` about no mapped encoder (delegating encoder expects an `{id}` prefix on stored passwords). - Storing plaintext passwords -> encoder mismatch; always store encoded values. - Blocking inside `findByUsername` defeats the reactive model and can starve the event loop. - Distinguishing 'user not found' from 'wrong password' in responses enables **user enumeration** — Spring deliberately treats both as bad credentials. ## When to use Use `ReactiveUserDetailsService` for classic username/password auth in a reactive app. For token-based (JWT/OAuth2 resource server) auth you typically don't need it — you configure `oauth2ResourceServer` and a `ReactiveJwtDecoder` instead.