Authentification HTTP Basic

Qu'est-ce que l'Authentification HTTP Basic ?

L'Authentification HTTP Basic est l'un des mécanismes d'authentification les plus simples définis dans la spécification HTTP (RFC 7617, anciennement RFC 2617). Son fonctionnement est direct :

1. Lorsqu'un client non authentifié tente d'accéder à une ressource protégée, le serveur répond avec un code de statut 401 Unauthorized et un en-tête WWW-Authenticate: Basic realm="NomDuDomaineDeProtection".
2. Le client (navigateur ou programme) invite alors l'utilisateur à saisir un nom d'utilisateur et un mot de passe.
3. Le client combine le nom d'utilisateur et le mot de passe avec un deux-points (username:password), encode cette chaîne en Base64, et renvoie la requête originale en ajoutant un en-tête Authorization: Basic .
4. Le serveur reçoit la requête, décode les informations d'identification Base64, et vérifie si elles correspondent à un utilisateur valide. Si oui, il accorde l'accès ; sinon, il renvoie à nouveau une erreur 401.

Sa simplicité est son principal avantage : elle est largement supportée par les navigateurs et les clients HTTP sans nécessiter de cookies, de sessions complexes côté serveur (pour l'authentification elle-même), ou de redirections complexes.

Activation par défaut dans Spring Boot Security

Comme mentionné dans le chapitre sur l'intégration du starter de sécurité, lorsque vous ajoutez spring-boot-starter-security, l'auto-configuration de Spring Boot active par défaut plusieurs mécanismes, et l'authentification HTTP Basic est l'un d'eux, agissant souvent comme un fallback si aucun autre mécanisme plus spécifique (comme un formulaire de login) n'est explicitement configuré et prioritaire.

C'est pourquoi, après avoir ajouté le starter, votre navigateur affiche immédiatement une boîte de dialogue d'authentification native lorsque vous essayez d'accéder à l'application. Le serveur Spring Boot/Security envoie l'en-tête WWW-Authenticate: Basic realm="Realm" (le nom du realm est configurable), et le navigateur réagit en conséquence. C'est également pour cela que Spring Boot génère un utilisateur user avec un mot de passe aléatoire, afin qu'il y ait au moins une paire d'identifiants valides pour passer cette authentification initiale.

Configuration explicite (via `SecurityFilterChain`)

Bien qu'elle soit souvent activée par défaut, vous pouvez configurer explicitement (ou désactiver) l'authentification HTTP Basic lors de la personnalisation de votre chaîne de filtres de sécurité via un bean SecurityFilterChain.

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.security.config.annotation.web.builders.HttpSecurity;
import org.springframework.security.config.annotation.web.configuration.EnableWebSecurity;
import org.springframework.security.core.userdetails.User;
import org.springframework.security.core.userdetails.UserDetails;
import org.springframework.security.core.userdetails.UserDetailsService;
import org.springframework.security.provisioning.InMemoryUserDetailsManager;
import org.springframework.security.web.SecurityFilterChain;
import static org.springframework.security.config.Customizer.withDefaults;

@Configuration
@EnableWebSecurity
public class SecurityConfig {

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http
            .authorizeHttpRequests(authz -> authz
                // Toutes les requêtes nécessitent une authentification
                .anyRequest().authenticated()
            )
            // Active explicitement l'authentification HTTP Basic avec les paramètres par défaut
            .httpBasic(withDefaults()); 
            // Le withDefaults() applique une configuration de base, 
            // vous pourriez aussi passer un Customizer: .httpBasic(customizer -> customizer.realmName("MonAppRealm"))
            
            // Désactiver CSRF si c'est une API stateless (souvent le cas avec HTTP Basic pur)
            // .csrf(csrf -> csrf.disable()); 

        return http.build();
    }

    // Exemple simple d'utilisateurs en mémoire (remplace l'utilisateur généré)
    @Bean
    public UserDetailsService userDetailsService() {
        UserDetails user = User.withDefaultPasswordEncoder() // Attention: password encoder déprécié pour démo seulement
            .username("basicuser")
            .password("password123")
            .roles("USER")
            .build();
        UserDetails admin = User.withDefaultPasswordEncoder()
            .username("admin")
            .password("adminpass")
            .roles("ADMIN", "USER")
            .build();
        return new InMemoryUserDetailsManager(user, admin);
    }
}

Dans cette configuration, nous demandons explicitement via .httpBasic(withDefaults()) d'utiliser l'authentification HTTP Basic. Si vous omettez complètement la ligne .httpBasic(...) et n'ajoutez pas d'autre mécanisme comme .formLogin(...), Spring Security l'activera souvent quand même comme mécanisme de base pour protéger les endpoints spécifiés par authorizeHttpRequests.

Pour désactiver explicitement HTTP Basic, vous pourriez utiliser .httpBasic(basic -> basic.disable()).

Cas d'utilisation et limites

Quand utiliser HTTP Basic ?

• Simplicité extrême : Pour des prototypes rapides, des outils internes simples, ou des API où la sécurité n'est pas la préoccupation majeure (par exemple, sur un réseau entièrement sécurisé et isolé).
• API Stateless : Comme il n'y a pas de session ou de cookie impliqué, il s'intègre bien avec une approche stateless. Chaque requête porte ses propres informations d'identification.
• Tests initiaux : Utile pendant le développement pour avoir une sécurité minimale sans configurer de formulaire complexe.

Cependant, HTTP Basic présente une limite de sécurité majeure : les informations d'identification (nom d'utilisateur et mot de passe), bien qu'encodées en Base64, sont transmises en quasi clair dans l'en-tête `Authorization`. Base64 n'est pas un chiffrement, c'est un simple encodage facilement réversible. Toute personne interceptant la requête sur un réseau non sécurisé (HTTP) peut facilement récupérer le mot de passe.

La nécessité absolue de HTTPS

En raison de la transmission en clair des identifiants, l'utilisation de l'authentification HTTP Basic n'est absolument pas recommandée sur des connexions non chiffrées (HTTP). Elle ne devrait être envisagée que sur des connexions sécurisées par HTTPS (HTTP sur TLS/SSL).

HTTPS chiffre l'intégralité de la communication HTTP, y compris les en-têtes (comme l'en-tête `Authorization`). Par conséquent, même si les identifiants sont en Base64 *dans* l'en-tête, l'en-tête lui-même est chiffré pendant le transport, protégeant ainsi les identifiants contre l'interception réseau.

Malgré l'utilisation de HTTPS, HTTP Basic reste vulnérable si les identifiants sont faibles ou si le client ou le serveur sont compromis d'une autre manière. De plus, il n'offre pas de mécanisme standard pour la déconnexion (le navigateur met souvent en cache les identifiants pour la session) et est moins convivial qu'un formulaire de connexion pour les applications web interactives.

Conclusion : Simple mais limité

L'authentification HTTP Basic est un mécanisme fondamental et simple, automatiquement pris en charge par Spring Boot Security comme configuration de base. Elle est facile à comprendre et à mettre en oeuvre, et peut être utile dans certains contextes spécifiques, notamment pour des API stateless simples ou lors du développement initial. Cependant, en raison de sa faiblesse intrinsèque liée à la transmission des identifiants en clair (sans HTTPS), elle est rarement le choix privilégié pour des applications modernes sécurisées nécessitant une authentification robuste. Dans la plupart des cas, elle sera remplacée par des mécanismes plus sécurisés et plus flexibles comme l'authentification par formulaire, l'authentification basée sur des tokens (JWT), ou des protocoles comme OAuth2/OpenID Connect, surtout pour les applications exposées sur Internet.