Integrar un JWT Filter dentro del Spring Security Filter Chain permite reemplazar la autenticación HTTP Basic por una validación basada en JSON Web Token, haciendo que tu API sea stateless y más segura. Esta configuración es clave para desarrolladores backend que construyen APIs REST con Spring Boot y necesitan controlar quién accede a cada endpoint.

Por qué reemplazar HTTP Basic por un filtro JWT

Cuando una petición llega a tu aplicación, atraviesa una cadena de filtros de seguridad. Si dejas HTTP Basic activo, cada petición se autentica con usuario y contraseña, lo cual no escala bien en APIs modernas.

La idea es insertar tu filtro propio en esa cadena para que valide el token, y si todo está en orden, cargue la autenticación dentro del SecurityContextHolder. Así, el resto de filtros confía en que la petición ya está autenticada y la deja pasar.

¿Qué hace el SecurityContextHolder? Es el contenedor donde Spring Security guarda la autenticación del usuario activo durante una petición. Si tu filtro carga ahí un Authentication válido, los siguientes filtros no vuelven a pedir credenciales.

Cómo agregar el JWT Filter al SecurityConfig

Dentro de la clase SecurityConfig, primero inyectas el filtro como dependencia con private final JwtFilter jwtFilter y lo incluyes en el constructor con autowiring [01:30].

Luego reemplazas la línea de HTTP Basic por addFilterBefore. Spring te da varias opciones para insertar filtros:

• addFilter: lo agrega al final de la cadena.
• addFilterBefore: lo coloca antes de un filtro específico.
• addFilterAfter: lo ubica después de uno específico.
• addFilterAt: lo posiciona en un lugar exacto.

La elección recomendada es addFilterBefore(jwtFilter, UsernamePasswordAuthenticationFilter.class). Aunque también funciona con BasicAuthenticationFilter.class, el estándar de la industria es usar el UsernamePasswordAuthenticationFilter porque es el primer filtro de autenticación que tiene Spring [02:45].

Cómo configurar la API como stateless

Una API stateless no almacena sesiones: cada petición se valida como nueva. Para lograrlo, después de la configuración de CORS y antes de authorizeHttpRequests, agregas:

java .sessionManagement() .sessionCreationPolicy(SessionCreationPolicy.STATELESS) .and()

Con esto le dices a Spring que no cree ni mantenga sesiones HTTP. Cada request trae su propio JWT y se valida desde cero [03:30].

¿Qué significa que una API sea stateless? Que el servidor no guarda información entre peticiones. El cliente debe enviar su token de autenticación en cada llamada porque el backend no recuerda nada del request anterior.

Cómo probar el flujo de autenticación con JWT

Al lanzar la aplicación, en la consola verás que el JwtFilter aparece dentro del Filter Chain, justo en la posición donde lo configuraste.

Si intentas autenticar con Basic Auth (usuario admin, contraseña admin123) recibirás un 403 Forbidden, porque ese esquema ya no es válido. El flujo correcto ahora es:

1. Iniciar sesión para obtener un JWT.
2. Seleccionar Bearer Token en Postman.
3. Pegar el token en el header Authorization.
4. Lanzar la petición y recibir un 200 OK.

En la consola verás que el filtro recuperó el UserEntity desde el UserDetailsService y construyó un UsernamePasswordAuthenticationToken con el principal (admin), las credenciales protegidas y dos authorities: el rol admin y el random order [05:50].

Cómo agregar detalles como IP y sesión al contexto

Antes de cargar la autenticación al contexto, puedes enriquecerla con detalles del request. Esto es útil para auditoría o trazabilidad:

java authenticationToken.setDetails( new WebAuthenticationDetailsSource().buildDetails(request) );

Después de este cambio, al imprimir la autenticación verás dos campos nuevos: el remoteIpAddress con la IP del cliente y el sessionId, que será null porque la API es stateless [07:20].

Qué pasa si alguien manipula el token

Este es el punto donde la firma del JWT muestra su valor. Si tomas un token válido, lo pegas en jwt.io y cambias el campo sub de admin a customer, la firma deja de coincidir.

Al enviar esa petición manipulada a Postman, el servidor responde con 403 Forbidden, porque el filtro detectó que la firma no es válida y rechazó la autenticación [08:40].

¿Por qué falla un JWT modificado? Porque su firma se genera con una clave secreta del servidor. Si cambias el payload, la firma original ya no corresponde y el filtro lo identifica como inválido.

Con esta configuración tu proyecto queda protegido por un esquema profesional: API stateless, autenticación por JWT y detalles de request capturados para auditoría. ¿Ya probaste manipular tu propio token para ver el 403 en acción? Cuéntame en los comentarios qué validaciones extra agregarías a tu filtro.