Authentication vs Authorization in Spring Security

Direct Answer

Authentication answers "Who are you?" — verifies identity by checking credentials and produces an Authentication object stored in the SecurityContext. Authorization answers "What are you allowed to do?" — checks the principal's GrantedAuthority collection against required permissions for a resource. Spring enforces them as two distinct, sequential steps: AuthenticationManager first, then AuthorizationManager (or @PreAuthorize). The clearest signal that you understand the difference: 401 means unauthenticated; 403 means authenticated-but-unauthorized — never return 403 to anonymous requests, it leaks resource existence.

Code Example

Authentication asks who are you? and produces an Authentication object in the SecurityContext. Authorization asks what can you do? and checks roles/authorities against that object. Spring Security pipelines both in a filter chain.

@Configuration
@EnableWebSecurity
@EnableMethodSecurity     // enables @PreAuthorize / @PostAuthorize
public class SecurityConfig {

    // ---- AUTHENTICATION ----
    @Bean
    public UserDetailsService users(PasswordEncoder encoder) {
        UserDetails alice = User.withUsername("alice")
            .password(encoder.encode("secret"))
            .roles("USER").build();
        UserDetails admin = User.withUsername("admin")
            .password(encoder.encode("secret"))
            .roles("USER", "ADMIN").build();
        return new InMemoryUserDetailsManager(alice, admin);
    }

    @Bean PasswordEncoder encoder() { return new BCryptPasswordEncoder(); }

    // ---- AUTHORIZATION ----
    @Bean
    public SecurityFilterChain chain(HttpSecurity http) throws Exception {
        return http
            .authorizeHttpRequests(a -> a
                .requestMatchers("/public/**").permitAll()                  // no auth required
                .requestMatchers("/admin/**").hasRole("ADMIN")              // role-based
                .requestMatchers(HttpMethod.DELETE, "/api/**").hasAuthority("SCOPE_write")
                .anyRequest().authenticated())                              // must be logged in
            .httpBasic(Customizer.withDefaults())                           // AuthN mechanism
            .build();
    }
}

// Fine-grained authorization on a service method
@Service
public class OrderService {
    @PreAuthorize("hasRole('ADMIN') or #order.ownerId == authentication.name")
    public void delete(Order order) { /* ... */ }
}

• The AuthenticationManager (invoked by filters such as UsernamePasswordAuthenticationFilter) validates credentials and returns an Authentication with authorities. On success it lands in SecurityContextHolder.getContext().
• The authorization layer (AuthorizationManager, @PreAuthorize) is the only thing that decides whether a caller may invoke a method — URL rules are coarse, method annotations are precise, use both.
• hasRole("ADMIN") is sugar for hasAuthority("ROLE_ADMIN"). Keep the convention consistent or bugs creep in (the ROLE_ prefix is implicit only on hasRole).
• Never rely on the UI hiding a button as authorization — the UI is a hint, the server is the source of truth.

Common Mistakes & Pitfalls

Conflating the two concepts, or not knowing that Authorization can only work after Authentication populates the SecurityContext.