Spring Security

Authentication answers "who are you?" — verifying an identity, typically via credentials (username/password, a JWT, an OAuth token). Authorization answers "what are you allowed to do?" — once identity is established, deciding whether this specific user can access a given resource or perform a given action (based on roles/ authorities/permissions). Authentication always happens first; authorization decisions are meaningless without a verified identity to check permissions against.

Spring Security intercepts every incoming request through a chain of servlet filters, each responsible for one concern, before the request ever reaches your controller.

Request
   |
   v
CorsFilter                       -- handles CORS preflight/headers
   |
   v
CsrfFilter                       -- validates CSRF token (if enabled)
   |
   v
UsernamePasswordAuthenticationFilter / your JWT filter
   |                                -- authenticates the request, populates SecurityContext
   v
ExceptionTranslationFilter       -- catches AccessDeniedException/AuthenticationException
   |
   v
FilterSecurityInterceptor        -- final authorization check against configured rules
   |
   v
Your DispatcherServlet / Controller

If any filter rejects the request (e.g. no valid token), it short-circuits — the request never reaches your controller at all.

The typical flow: a login endpoint validates credentials and returns a signed JWT; the client sends that token in the Authorization: Bearer <token> header on every subsequent request; a custom filter (extending OncePerRequestFilter, so it runs exactly once per request) intercepts each request, validates the token's signature and expiry, and — if valid — manually populates the SecurityContext with an authenticated principal, before letting the request continue down the chain.

class JwtAuthFilter extends OncePerRequestFilter {
    protected void doFilterInternal(HttpServletRequest req, HttpServletResponse res, FilterChain chain) {
        String token = extractBearerToken(req);
        if (token != null && jwtUtil.isValid(token)) {
            Authentication auth = jwtUtil.buildAuthentication(token);
            SecurityContextHolder.getContext().setAuthentication(auth);
        }
        chain.doFilter(req, res); // continue regardless -- downstream authorization still enforces access
    }
}

Because the server never stores session state, this is fully stateless — any instance in a scaled-out cluster can validate any request's token independently. See JWT vs Session/OAuth → for the deeper trade-off discussion (revocation, token size, refresh tokens).

Storing plaintext passwords means a single database breach exposes every user's actual password — devastating given how often people reuse passwords across services. PasswordEncoder implementations like BCrypt apply a one-way, salted hash: the same password hashes to a different output every time (a random salt is embedded in the result), and the hash can't be reversed back to the original password. Login compares by re-hashing the submitted password with the stored salt and checking for a match — the plaintext password itself is never stored or needed again after signup.

PasswordEncoder encoder = new BCryptPasswordEncoder();
String hash = encoder.encode("myPassword123");     // different output every call
encoder.matches("myPassword123", hash);             // true -- verifies without ever decrypting

BCrypt is also deliberately slow (configurable work factor) — a defense against brute-force/rainbow-table attacks, unlike a fast general-purpose hash like plain SHA-256.