Securing APIs with Spring Security

So far, biblio-api accepts everyone. Anyone can create a book, delete someone else's, or read the entire catalog. On a development machine that's convenient; from the first deployment on, it's an open door.

Securing an API raises two distinct questions, and confusing them is the first source of mistakes. Who are you? is a matter of authentication, and the failure response is 401 Unauthorized. Are you allowed to do this? is a matter of authorization, and the failure response is 403 Forbidden. A properly authenticated user who tries to delete a book without having the right role must receive a 403, not a 401 — the latter would make them think their credentials are invalid and push them to log in again in a loop.

Anyone looking for help online on this topic faces a particular difficulty. Spring Security 6, bundled with Spring Boot 3, has removed WebSecurityConfigurerAdapter. The class isn't deprecated: it no longer exists. Yet most of the articles, answers, and examples indexed over the past ten years rely on it, and a reader who copies them gets a compilation error that none of those articles explains. Configuration is now declared through beans, in particular a SecurityFilterChain bean.