Seguridad reactiva con WebFlux

Spring Security funciona igual en espíritu con Spring WebFlux: autenticación, autorización, CSRF, OAuth2 y JWT son los mismos conceptos. Lo que cambia es la fontanería, porque en una aplicación reactiva una petición no tiene un hilo propio.

Analogía

Un camarero para todo el restaurante

Si cada camarero atiende a todas las mesas, no puede “recordar” quién eres por ser tu camarero: la información tiene que ir en la comanda. En WebFlux, la comanda es el contexto de Reactor.

En el mundo realEn tu sistema

Un camarero por mesa que recuerda lo que pedisteServlet: un hilo por petición, contexto en un ThreadLocal

Pocos camareros que atienden todas las mesas por turnosReactivo: pocos hilos que se reparten muchas peticiones

Los datos del cliente viajan apuntados en la comandaEl SecurityContext viaja en el contexto de Reactor

Las piezas equivalentes

Servlet (Spring MVC)	Reactivo (WebFlux)
@EnableWebSecurity	@EnableWebFluxSecurity
SecurityFilterChain + HttpSecurity	SecurityWebFilterChain + ServerHttpSecurity
authorizeHttpRequests / requestMatchers / anyRequest	authorizeExchange / pathMatchers / anyExchange
SecurityContextHolder (ThreadLocal)	ReactiveSecurityContextHolder (contexto de Reactor)
UserDetailsService	ReactiveUserDetailsService (MapReactiveUserDetailsService en memoria)
JwtDecoder	ReactiveJwtDecoder
@EnableMethodSecurity	@EnableReactiveMethodSecurity (métodos que devuelven Mono/Flux)
MockMvc + jwt()	WebTestClient + mockJwt()

Configuración

SecurityConfig.java

@Configuration
@EnableWebFluxSecurity
@EnableReactiveMethodSecurity
class SecurityConfig {

    @Bean
    SecurityWebFilterChain api(ServerHttpSecurity http) {
        http
            .authorizeExchange(ex -> ex
                .pathMatchers(HttpMethod.GET, "/api/public/**").permitAll()
                .pathMatchers("/api/admin/**").hasAuthority("SCOPE_notes:admin")
                .anyExchange().authenticated())
            .oauth2ResourceServer(o -> o.jwt(Customizer.withDefaults()))
            .csrf(ServerHttpSecurity.CsrfSpec::disable);   // API stateless con Bearer
        return http.build();
    }
}

La estructura es la misma que ya conoces: reglas de arriba abajo, un mecanismo de autenticación y la decisión sobre CSRF. Las propiedades de issuer-uri y audiences del resource server también son las mismas.

El usuario actual

1. Petición
3. ReactorContextWebFilterescribe el SecurityContext en el contexto de Reactor
5. Tu pipeline Mono/Fluxlo lee con ReactiveSecurityContextHolder.getContext()

El contexto viaja con la suscripción, no con el hilo: sobrevive a los cambios de hilo de Reactor.

Evita

// En WebFlux esto devuelve null: no hay ThreadLocal fiable
@GetMapping("/api/me")
Mono<String> me() {
    return Mono.just(SecurityContextHolder.getContext()
        .getAuthentication().getName());
}

Prefiere

@GetMapping("/api/me")
Mono<String> me() {
    return ReactiveSecurityContextHolder.getContext()
        .map(ctx -> ctx.getAuthentication().getName());
}

// …o, más simple, como parámetro:
@GetMapping("/api/me2")
Mono<String> me2(@AuthenticationPrincipal Jwt jwt) {
    return Mono.just(jwt.getSubject());
}

Seguridad por método

Con @EnableReactiveMethodSecurity, @PreAuthorize y @PostAuthorize funcionan sobre métodos que devuelven Mono o Flux; la expresión se evalúa dentro del pipeline:

NoteService.java

@PreAuthorize("hasAuthority('SCOPE_notes:admin')")
public Flux<Note> all() {
    return repo.findAll();
}

public Mono<Note> get(Long id, String owner) {
    return repo.findByIdAndOwner(id, owner)
        .switchIfEmpty(Mono.error(new ResponseStatusException(HttpStatus.NOT_FOUND)));
}

Trampa común

Bloquear dentro de un pipeline reactivo

Llamar a .block(), a un cliente JDBC o a una librería bloqueante dentro de un handler de WebFlux deja sin hilos al servidor: con pocas peticiones lentas, todo se para. Esto incluye la seguridad: un ReactiveUserDetailsService que consulta la base de datos con JDBC bloqueante es un cuello de botella. Usa R2DBC o envuelve el código bloqueante con subscribeOn(Schedulers.boundedElastic()).

Idea clave

Elegir WebFlux no cambia qué proteges ni cómo razonas: cadena de filtros, autenticación, autorización por URL y por objeto, CSRF y tokens son idénticos. Cambia dónde vive el contexto y que todo devuelve Mono o Flux.

Probar con WebTestClient

NoteRoutesTest.java

@WebFluxTest(NoteController.class)
@Import(SecurityConfig.class)
class NoteRoutesTest {

    @Autowired WebTestClient client;
    @MockitoBean NoteService notes;

    @Test
    void anonimo_recibe401() {
        client.get().uri("/api/notes").exchange().expectStatus().isUnauthorized();
    }

    @Test
    void sinScopeAdmin_recibe403() {
        client.mutateWith(mockJwt().authorities(new SimpleGrantedAuthority("SCOPE_notes:read")))
            .get().uri("/api/admin/notes")
            .exchange()
            .expectStatus().isForbidden();
    }
}

Mini lab · 30 min

La API de notas, en reactivo

Marcar como completado

Objetivo: Portar la configuración de seguridad de la API de notas a WebFlux y comprobar que las reglas se mantienen.

1. Crea un proyecto con spring-boot-starter-webflux, spring-boot-starter-security y el starter de resource server.
2. Escribe un SecurityWebFilterChain equivalente a la cadena de la API de la lección de JWT: lectura con SCOPE_notes:read, escritura con SCOPE_notes:write, admin con SCOPE_notes:admin.
3. Implementa GET /api/me leyendo el usuario con ReactiveSecurityContextHolder.
4. Escribe la matriz de autorización con WebTestClient y mockJwt().

Preguntas:

• Si en el paso 3 usas SecurityContextHolder.getContext(), ¿qué obtienes y por qué?
• ¿Qué método sustituye a requestMatchers y cuál a anyRequest?
• Tu ReactiveUserDetailsService usa un repositorio JPA. ¿Qué problema tiene?

Pista

Piensa en qué hilo ejecuta tu código en WebFlux y si es el mismo que el que inició la petición.

Mostrar respuestaOcultar respuesta

• Un contexto vacío (autenticación null): SecurityContextHolder usa un ThreadLocal, y en WebFlux el código de la petición puede ejecutarse en cualquier hilo del event loop. El contexto de seguridad vive en el contexto de Reactor y se lee con ReactiveSecurityContextHolder.getContext() (o con @AuthenticationPrincipal).
• pathMatchers(...) sustituye a requestMatchers(...) y anyExchange() a anyRequest(), dentro de authorizeExchange.
• JPA es bloqueante: cada login bloquea un hilo del event loop, y con pocos usuarios simultáneos el servidor deja de responder. Usa R2DBC, o aísla la llamada bloqueante con Mono.fromCallable(...).subscribeOn(Schedulers.boundedElastic()).

En resumen

• Mismos conceptos, otras piezas: SecurityWebFilterChain, ServerHttpSecurity, authorizeExchange, pathMatchers.
• El contexto vive en Reactor: ReactiveSecurityContextHolder o @AuthenticationPrincipal, nunca SecurityContextHolder.
• @EnableReactiveMethodSecurity para métodos Mono/Flux; nada bloqueante en el pipeline.
• Pruebas con WebTestClient y mockJwt().