Sécurisation des API avec Spring Security

Jusqu'ici, biblio-api accepte tout le monde. N'importe qui peut créer un livre, en supprimer un autre, ou lire l'intégralité du catalogue. Sur un poste de développement c'est confortable ; dès le premier déploiement, c'est une porte ouverte.

Sécuriser une API pose deux questions distinctes, et les confondre est la première source d'erreurs. Qui êtes-vous ? relève de l'authentification, et la réponse d'échec est 401 Unauthorized. Avez-vous le droit de faire ceci ? relève de l'autorisation, et la réponse d'échec est 403 Forbidden. Un utilisateur correctement authentifié qui tente de supprimer un livre sans en avoir le rôle doit recevoir un 403, pas un 401 — le second lui ferait croire que ses identifiants sont invalides et le pousserait à se reconnecter en boucle.

Une difficulté particulière attend celui qui cherche de l'aide en ligne sur ce sujet. Spring Security 6, embarqué par Spring Boot 3, a supprimé WebSecurityConfigurerAdapter. La classe n'est pas dépréciée : elle n'existe plus. Or la majorité des articles, réponses et exemples indexés depuis dix ans reposent dessus, et un lecteur qui les recopie obtient une erreur de compilation qu'aucun de ces articles n'explique. La configuration se déclare désormais par des beans, en particulier un bean SecurityFilterChain.