public final class HttpSecurity

Builds one SecurityFilterChain. A @Bean method that returns a chain declares a parameter of this type and is handed a new one:

@Bean
SecurityFilterChain web(HttpSecurity http) {
    http.authorizeHttpRequests(auth -> auth
            .requestMatchers("/public/**").permitAll()
            .anyRequest().authenticated())
        .formLogin(Customizer.withDefaults())
        .httpBasic(Customizer.withDefaults());
    return http.build();
}

Out of the box a chain guards every request, writes the security headers, keeps who is signed in in the HTTP session, protects that session against CSRF and gives a request nobody signed in for an anonymous authentication. It has no way of signing in and no authorization rules until it is given them.

Everything else is there only when the chain asks for it, and a server carries the code of only what its chains ask for: formLogin – which brings sign-out and the memory of where a request was going with it – httpBasic, oauth2Login, oauth2ResourceServer, authorizationServer, apiKey, rateLimit, rememberMe, mfa, webAuthn, logout and requestCache. A server that only verifies tokens has no login page, no password hashing and no user store in it. This makes two departures from Spring Security. The first: a chain without formLogin has no POST /logout until it calls logout.

The second: a chain whose session policy is SessionCreationPolicy.STATELESS keeps nothing a forged request could ride on, and has no CSRF filter unless csrf asks for one. One that takes HTTP Basic credentials from browsers should ask.

Users come from the application’s beans: a UserDetailsService and, if there is one, a PasswordEncoder and a UserDetailsPasswordService – or AuthenticationProvider beans, or an AuthenticationManager bean. A chain can also be told directly, with userDetailsService, authenticationProvider or authenticationManager.