A Simple Guide to Spring Security.

Lars Martens

14 Maart, 2025

Preface.

When I first started learning Spring Security, I found plenty of in-depth resources and tutorials, but I struggled to follow along. The problem was that I lacked a clear overview, a mental picture of how everything fit together. Without that foundation, all the detailed information felt overwhelming and disconnected. I was "not seeing the forest for the trees." Which isn't that surprising, Spring Security is huge when you really want to understand all its intricacies.

And I'm pretty sure I'm not the only person who’s experienced this. On r/SpringBoot, the largest Reddit community dedicated to the Spring framework, one of the most upvoted posts of all time is titled "I hate Spring Security." You can read that post here.
In the post, the author shared their frustration, saying: "I keep trying to love Spring Boot, but the security is so damn complex you forget where you are. Am I supposed to ‘memorize’ all these functions and then call myself an ‘expert’ when I do?"

That is why, in this article, I'm taking a different approach. Instead of aiming to be a comprehensive guide covering every aspect of Spring Security, my goal is to teach only the minimum you need to know to be able to implement Spring Security, so that the information stays digestible and approachable.

In order to achieve this goal, I devided this article into three parts:
- First I'm going to give you a visual overview of the security flow of a Spring application. Having such a visual "roadmap" makes it much easier to understand the intricacies because it prevents you from feeling lost and gives you a clearer, big-picture perspective.
- In the second part, we are going to focus on the basic building block of Spring Security. So, we are not going to touch on every aspect of the security flow, but only on those parts that are required to be able to implement basic (form based) security.
- In the third part, we are going to take a more hands-on approach and show you how to built a very simple web application and how to secure it using the basics of Spring Security.

If by the end of this three part series, you understand the basic building blocks of Spring Security and how they fit together, then I will consider this a success. Once you have that solid foundation, diving into the details becomes a lot easier.

The article is a little long to read on a mobile device and it's not optimized for mobile either, so bookmark it and come back later.

Part One: A Visual Overview of the Security Flow.

The process begins when a user makes an HTTP request to a protected endpoint in our Spring Boot application.

The user tries to access a protected resource (e.g., a web page, REST API, or UI component) or attempts to log in using a login form or an API request.

The request first encounters the SecurityFilterChain, which is a series of filters that process the request sequentially. The SecurityFilterChain is configured in our Spring Security configuration class.

For form-based login, the UsernamePasswordAuthenticationFilter intercepts the request and extracts the username and password. It then creates an Authentication object (specifically a UsernamePasswordAuthenticationToken) with status set to unauthenticated.

The filter delegates the authentication process to the AuthenticationManager. The most common implementation of AuthenticationManager is ProviderManager, which maintains a list of AuthenticationProvider instances. The AuthenticationManager iterates through the available AuthenticationProviders until one can authenticate the request.

The AuthenticationProvider that is typically used for username/password authentication is the DaoAuthenticationProvider. The DaoAuthenticationProvider is a Spring Security class that integrates authentication logic with a Data Access Object (DAO). This provider allows Spring Security to authenticate users by comparing the provided credentials (username/password) against the data stored in a persistent data source, usually a database.

Some other AuthenticationProviders are:
- AnonymousAuthenticationProvider. Provides anonymous authentication for users who haven’t logged in. Is used when anonymous() is enabled in security config.
- JwtAuthenticationProvider (For JWT Authentication). Extracts and verifies JSON Web Tokens (JWTs). Common in stateless REST APIs.
- OAuth2LoginAuthenticationProvider (For OAuth 2.0 Login). Handles authentication via OAuth 2.0 Authorization Code flow. Works with external providers like Google, Facebook, GitHub.

The AuthenticationProvider calls the UserDetailsService to load user-specific data. This service retrieves user information from a data store (memory, database, LDAP, etc.).

The UserDetailsService returns a UserDetails object containing the user's username, password, authorities (roles/permissions), and account status (enabled, expired, locked, etc.).

The AuthenticationProvider uses a PasswordEncoder to verify if the provided password matches the encoded password stored for the user. A PasswordEncoder is responsible for encoding passwords and comparing hashed versions of passwords. The main goal of using a PasswordEncoder is to avoid storing plain-text passwords. Spring Security provides several implementations like BCryptPasswordEncoder, Pbkdf2PasswordEncoder, etc. Each implementation uses a different encoding algorithm and has different security characteristics, such as hashing strength, performance, and vulnerability to specific types of attacks.

With the UserDetails object, the AuthenticationProvider:
- Compares passwords using the PasswordEncoder.
- Verifies account status (not expired, locked, etc.).
- If successful, creates a fully populated Authentication object with status set to authenticated.

The AuthenticationManager receives the authenticated Authentication object and returns it to the calling filter.

The filter receives the authenticated Authentication object and does the following:
- Creates an authentication session if configured. Note: In some modern applications, particularly stateless REST APIs (such as when using JWT tokens), session creation is not typically used. Instead, authentication information is sent via HTTP headers and Spring Security will not create a session.
- Stores the authentication in the SecurityContext.
- Triggers the AuthenticationSuccessHandler which typically redirects to a success page or returns a success response.

Post-Authentication.

After successful authentication: The request continues through the filter chain. Spring Security's authorization filters check if the authenticated user has the required permissions for the requested resource. If authorized, the request reaches the controller/endpoint and the resource will be presented to the user.

Part Two: Understanding the Basics →