Spring Security

DelegatingFilterProxy is a servlet Filter registered with the container that forwards requests to a Spring-managed filter bean (the security filter chain). It lets Spring beans act as filters even though the container created the proxy.

It's a filter that catches two security exceptions thrown further down the chain — AuthenticationException (not logged in) and AccessDeniedException (logged in but not allowed) — and turns them into an HTTP response instead of an error page.

FilterChainProxy is the single servlet filter Spring Security registers. For each request it picks the first matching SecurityFilterChain and runs that chain's security filters in order.

Spring Security is a chain of servlet filters run in a fixed order. Each filter does one job (load context, check CSRF, authenticate, authorize). Order matters because later filters depend on what earlier ones set up — e.g. you must load the user before checking permissions.

You write a method annotated with @Bean that takes an HttpSecurity object, configures the rules on it, and returns http.build(), which produces a SecurityFilterChain. Spring registers it to secure your HTTP requests.

formLogin() turns on a browser login form. Spring adds UsernamePasswordAuthenticationFilter, which intercepts the POST to /login, reads the username and password fields, and asks the AuthenticationManager to verify them.

The logout() DSL wires up a LogoutFilter. When a user POSTs to /logout, the filter clears the logged-in user from the SecurityContext, invalidates the HTTP session, and redirects to a success page (default /login?logout).

AuthenticationManager has one method, authenticate(Authentication). It returns a fully authenticated Authentication if credentials are valid, throws an AuthenticationException if they are invalid, or returns null if it cannot decide.

PasswordEncoder is an interface that turns a raw password into a one-way, salted hash. You store the hash, never the plaintext, so a database leak doesn't expose real passwords. Its matches() method verifies a login attempt.

UserDetailsService is an interface with one method, loadUserByUsername(String), that looks up a user by name and returns a UserDetails object holding the username, encoded password, and authorities (roles). It throws UsernameNotFoundException if no user exists.

It's the component that produces the HTTP 403 (Forbidden) response when a logged-in user tries to access something they're not allowed to. It runs after an AccessDeniedException is thrown.

AuthorizationManager is Spring Security's interface that decides whether an authenticated user is allowed to access something. In Spring Security 6 it replaced the older AccessDecisionManager and voter system.

authorizeHttpRequests is where you declare which URLs need authorization. You list rules with requestMatchers(path) and choose an access rule like permitAll() (open to everyone) or authenticated() (must be logged in).

hasRole('ADMIN') automatically checks for the authority 'ROLE_ADMIN' by adding the ROLE_ prefix. hasAuthority('ROLE_ADMIN') checks the exact string you pass, with no prefix added. They match the same authority only if you include ROLE_ yourself.

Implement AccessDeniedHandler, set the response status to 403, set content type to application/json, and write your JSON body. Register it via http.exceptionHandling(e -> e.accessDeniedHandler(yourHandler)).

@EnableMethodSecurity turns on security checks on individual methods (not just URLs). prePostEnabled activates @PreAuthorize/@PostAuthorize (on by default), securedEnabled activates @Secured, and jsr250Enabled activates @RolesAllowed. You put it on a @Configuration class.

@PreAuthorize checks a rule before a method runs; @PostAuthorize checks after it returns. You enable them by adding @EnableMethodSecurity to a configuration class. If the rule is false, access is denied with an exception.

Both are method-level annotations that restrict who can call a method based on their roles. @RolesAllowed is a Java standard (JSR-250); @Secured is Spring's own. You list allowed roles and Spring blocks everyone else.

Implement the PermissionEvaluator interface (its two hasPermission methods) with your own logic, then publish a MethodSecurityExpressionHandler bean, calling setPermissionEvaluator() so @PreAuthorize's hasPermission() uses it.

You can reference method arguments by name (or #p0, #p1), the current user via authentication and principal, and — only in @PostAuthorize — the method's result via returnObject. You combine them with helpers like hasRole() and hasAuthority().

Spring Authorization Server is a standalone project that turns your app into an OAuth2/OIDC provider — it issues tokens. A RegisteredClient is one app allowed to request tokens; RegisteredClientRepository stores and looks up those clients.

JwtTimestampValidator checks the token's time claims: it rejects tokens that are expired (exp) or not yet valid (nbf). It allows a default 60-second clock skew so tokens are not rejected just because server clocks differ slightly.

An OAuth2AuthorizedClient holds the access token (and optional refresh token) your app got to call another API on a user's behalf. oauth2Client() lets your app CALL other APIs; oauth2Login() logs the USER into your app.

oauth2Login() lets users sign in to your app using an external provider like Google or GitHub. It uses the OAuth2 authorization-code flow: Spring redirects the user to the provider, gets a code back, and exchanges it for tokens to log the user in.

In the SecurityFilterChain, call http.oauth2ResourceServer(oauth2 -> oauth2.jwt(...)). Add a jwk-set-uri or issuer-uri in application.yml so Spring can fetch the keys and verify each incoming Bearer token's signature.

CORS lets a browser page from one origin call an API on another origin. In Spring Security you turn it on with http.cors() in the SecurityFilterChain and provide a CorsConfigurationSource bean that lists allowed origins, methods, and headers.

CSRF tricks a logged-in user's browser into sending an unwanted state-changing request using their cookies. Spring Security defends with a secret token (CsrfFilter) that must accompany every POST/PUT/DELETE/PATCH, which an attacker's site cannot know.

By default Spring Security adds protective response headers automatically: Cache-Control (no-store), X-Content-Type-Options: nosniff, X-Frame-Options: DENY, and Strict-Transport-Security (HSTS) on HTTPS requests. You don't configure anything to get them.

Session fixation is when an attacker forces a victim to use a known session ID, then hijacks it after login. Spring Security defends by changing the session ID at login (changeSessionId), so the old ID is useless.

With false (default) a new login is allowed and the oldest session is expired. With true the new login is refused (throws SessionAuthenticationException) and existing sessions stay alive — old sessions win over new ones.

Use SecurityMockMvcRequestPostProcessors: mockMvc.perform(get("/").with(user("alice").roles("ADMIN"))) runs the request as that user. State-changing requests (POST/PUT/DELETE) need .with(csrf()) because CSRF protection rejects them without a valid token.

In WebFlux, ReactiveSecurityContextHolder stores the logged-in user's SecurityContext inside the Reactor Context (attached to the request's reactive stream) instead of a ThreadLocal, so it survives even when work hops between threads.

@EnableWebFluxSecurity turns on Spring Security for a reactive WebFlux app. You then declare a @Bean of type SecurityWebFilterChain that configures which URLs are protected and how users log in.

@WithMockUser runs a test as if a logged-in user made the request, without hitting a real login. By default the user is named 'user' with password 'password' and the role USER.

Either inject the user as a method parameter (@AuthenticationPrincipal MyUser user, or a Mono<Authentication>/Principal argument), or in a service compose ReactiveSecurityContextHolder.getContext().map(SecurityContext::getAuthentication).