El Basic Authentication Filter de Spring Security es el componente que intercepta tu petición HTTP y valida usuario y contraseña antes de permitir el acceso al recurso protegido. Entender su flujo interno te ayuda a depurar errores de autenticación y a diseñar esquemas de seguridad más sólidos en aplicaciones Java.

Lo interesante es que no trabaja solo: detrás de él hay una cadena de objetos coordinándose para resolver una sola pregunta, ¿este usuario es quien dice ser?

¿Qué hace el Basic Authentication Filter cuando llega una petición?

Cuando envías una petición a tu aplicación, el Spring Security Filter Chain la captura y empieza a pasarla por cada filtro de seguridad de manera encadenada. Al llegar al Basic Authentication Filter, el método que se ejecuta es doFilterInternal, y ahí inicia toda la verificación de credenciales.

En ese punto, el filtro construye un UsernamePasswordAuthenticationToken que contiene tres datos clave:

• El usuario dentro del campo principal.
• La contraseña dentro de credentials.
• Una lista de permisos vacía, porque todavía no se ha autenticado.

¿Qué es el Basic Authentication Filter? Es un filtro de Spring Security que intercepta peticiones HTTP con cabecera Basic Auth, extrae usuario y contraseña, y delega la validación al Authentication Manager.

¿Quién valida realmente la contraseña en Spring Security?

El filtro no valida nada por sí mismo. Lo que hace es delegar al Authentication Manager, cuya implementación por defecto es el ProviderManager [02:45]. Piénsalo como un coordinador: su trabajo es decidir qué provider usar según el tipo de autenticación, ya sea usuario y contraseña, LDAP o Auth0.

Para una petición Basic, el provider elegido es el DaoAuthenticationProvider, especializado en validar credenciales tipo usuario/contraseña.

¿Cómo se recupera el usuario antes de comparar la contraseña?

Antes de comparar nada, el flujo pasa por el AbstractUserDetailsAuthenticationProvider, donde ocurren tres cosas en orden:

1. Se determina el username recibido.
2. Se verifica que el usuario no esté ya en caché.
3. Se invoca el método retrieveUser, en la línea 133 de esa clase [04:30].

Ese método es abstracto, así que la implementación real vive en el DaoAuthenticationProvider, que en su línea 94 llama al UserDetailsService para cargar el usuario por su username.

¿Por qué se usa el InMemoryUserDetailsManager por defecto?

Cuando no defines un esquema de seguridad propio, Spring Boot genera automáticamente un usuario llamado user con una contraseña aleatoria que verás en la consola al arrancar la aplicación. Esa credencial vive en una lista en memoria gestionada por el InMemoryUserDetailsManager, y su método loadUserByUsername recorre esa lista buscando el usuario solicitado.

Es útil para prototipos y pruebas, pero en producción reemplazarías esta clase por una implementación que consulte tu base de datos.

¿Dónde se compara la contraseña enviada con la almacenada?

Una vez recuperado el usuario, el flujo regresa al AbstractUserDetailsAuthenticationProvider y entra al método de la línea 147, llamado additionalAuthenticationChecks [06:50]. Ahí ocurren dos validaciones:

• Que las credenciales recibidas no sean nulas, si lo son, se lanza una excepción.
• Que la contraseña de la petición coincida con la almacenada, si no coincide, se lanza otra excepción.

Si todo cuadra, el usuario queda autenticado y el resultado regresa por la cadena: del provider al Authentication Manager, y de ahí al BasicAuthenticationFilter en su línea 177.

¿Qué pasa si la contraseña no coincide? Spring Security lanza una BadCredentialsException desde additionalAuthenticationChecks y la petición termina con un status 401 sin avanzar al recurso protegido.

¿Cómo se guarda la sesión autenticada en Spring?

Cuando el filtro confirma la autenticación, hace una última cosa antes de soltar la petición hacia los siguientes filtros: crea un SecurityContext vacío y le asigna el objeto de autenticación recién validado. Ese contexto es lo que permite que, en cualquier punto posterior de la aplicación, puedas saber quién está autenticado.

Después de eso, la petición continúa por los filtros restantes y, si todo va bien, tu endpoint responde con un status 200 y el cuerpo esperado.

¿Por qué te conviene depurar Spring Security paso a paso?

Muchas personas desarrolladoras nos acostumbramos a usar frameworks sin entender qué hacen por dentro. Hacer debug del BasicAuthenticationFilter, del ProviderManager, del DaoAuthenticationProvider y del InMemoryUserDetailsManager te muestra que la autenticación no es magia, es una cadena ordenada de responsabilidades.

Una estrategia útil para revisarlo en IntelliJ IDEA es poner checkpoints en estos puntos clave:

• Primera línea de doFilterInternal para ver la petición entrante.
• Línea 176 del BasicAuthenticationFilter, donde se invoca al Authentication Manager.
• Línea 182 del ProviderManager, donde se elige el provider.
• Línea 94 del DaoAuthenticationProvider, donde se carga el usuario.
• Línea 147 del AbstractUserDetailsAuthenticationProvider, donde se compara la contraseña.

Con esos cinco puntos puedes seguir el viaje completo de una credencial desde que entra como cabecera HTTP hasta que se convierte en un SecurityContext activo.

¿Te ha pasado que una autenticación falla y no sabes en qué eslabón de la cadena se rompe? Cuéntame en los comentarios qué parte del flujo te ha dado más problemas.