How Spring Security Works
IntermediateSpring Security protects your application by inserting a chain of servlet filters in front of your controllers. Every request passes through these filters, which authenticate the caller (who are you?) and authorize the request (are you allowed?). It stores the authenticated identity in a SecurityContext, supports many mechanisms — form login, HTTP Basic, JWT, OAuth2 — and lets you secure endpoints declaratively. Understanding the filter chain demystifies the whole framework.
Think of Spring Security as airport security
Before you reach your gate (the controller), you pass through a series of checkpoints (the filter chain). One checks your ticket exists (authentication), another verifies you may enter this zone (authorization), another scans for prohibited items. Your verified identity is clipped to a lanyard (the SecurityContext) that every later checkpoint can read. If any checkpoint rejects you, you never reach the gate.
Step by Step
Key Concepts
Authentication vs Authorization
Authentication answers "who are you?" (verifying identity). Authorization answers "what may you do?" (checking permissions). Spring Security handles both, in that order.
SecurityFilterChain
The modern (component-based) way to configure Spring Security: a bean describing which requests are public, which need authentication, and which filters apply.
UserDetailsService
The interface Spring calls to load a user by username — from a database, LDAP, or elsewhere — returning their hashed password and granted authorities for verification.
Stateless JWT Auth
Instead of a server session, each request carries a signed JWT. A filter validates the signature and builds the SecurityContext per request, so the server holds no session state — ideal for scalable APIs.
Key Facts
- Passwords must be stored hashed with an adaptive algorithm — Spring Security defaults to BCrypt via the PasswordEncoder.
- For REST APIs using JWT, disable CSRF protection and sessions (stateless), since there is no session cookie to protect.
- Method-level security (@PreAuthorize("hasRole('ADMIN')")) complements URL rules for fine-grained control close to the business logic.
Real-World Applications
Securing a REST API with JWT
A custom filter reads the Authorization: Bearer token, validates its signature and expiry, loads the roles, and populates the SecurityContext — giving stateless, scalable auth with no server-side session.
Role-based admin endpoints
Configuring requestMatchers("/admin/**").hasRole("ADMIN") ensures only admins reach admin controllers, returning 403 to everyone else automatically.
Frequently Asked Questions
What is the Spring Security filter chain?
It is an ordered set of servlet filters Spring Security inserts before your controllers. Each request passes through filters that handle authentication, authorization, CSRF, CORS, and more. Only requests that pass all filters reach your application code.
How does JWT authentication work in Spring Security?
The client sends a signed JWT in the Authorization header. A custom filter validates the signature and expiry, extracts the user and roles from the token claims, and sets the SecurityContext for that request. No server session is stored, making it stateless and scalable.
What is the difference between authentication and authorization?
Authentication verifies identity (checking a password or token to confirm who the caller is). Authorization decides what that verified caller may do (checking roles/permissions against the requested resource). Spring authenticates first, then authorizes.
Should I disable CSRF for a REST API?
For a stateless API that authenticates with tokens (JWT) rather than session cookies, CSRF protection is generally disabled because there is no ambient cookie an attacker could exploit. For browser apps that use session cookies, keep CSRF protection enabled.