HTTP est sans état — alors comment les sessions fonctionnent-elles ?

HTTP est sans état par conception : chaque requête est autonome, et le serveur ne conserve aucune mémoire intégrée de qui a envoyé la précédente. Cette simplicité passe magnifiquement à l'échelle, mais elle entre en conflit avec le besoin de rester « connecté ». Les sessions sont la couche qui ajoute une continuité d'identité par-dessus un protocole sans état.

Le mécanisme central

Après une authentification unique, le serveur émet un identifiant et le navigateur le stocke — presque toujours dans un cookie. Comme les navigateurs attachent automatiquement les cookies à chaque requête ultérieure vers ce site, le serveur peut vous reconnaître à chaque requête sans que vous vous réauthentifiez. Le cookie est une identité au porteur, c'est pourquoi ses attributs (HttpOnly, Secure, SameSite) importent tant.

Deux façons de conserver l'état

Sessions côté serveur (avec état). Le cookie contient un ID de session opaque et aléatoire. Le serveur conserve les vraies données de session (ID utilisateur, rôles, expiration) dans son propre magasin — mémoire, Redis, une base de données — indexé par cet ID. Avantages : le serveur peut révoquer une session instantanément en la supprimant, et aucune donnée sensible ne réside dans le cookie. Coût : le serveur (ou un magasin partagé) doit conserver l'état, ce qui ajoute de l'infrastructure lors de la mise à l'échelle horizontale.

Jetons sans état (par exemple JWT). Le jeton lui-même porte les revendications (utilisateur, rôles, expiration) et est signé cryptographiquement. Le serveur vérifie la signature à chaque requête et fait confiance au contenu — aucune recherche nécessaire. Avantages : passe facilement à l'échelle sur de nombreux serveurs sans magasin de sessions partagé. Coûts : le jeton est valide jusqu'à son expiration, donc la révocation est difficile (vous avez besoin d'une liste de refus ou de durées de vie courtes plus des jetons de rafraîchissement), et des revendications surdimensionnées ou sensibles peuvent fuiter.

Pourquoi l'ID doit être imprévisible

Qu'il s'agisse d'un ID opaque ou d'un jeton signé, si un attaquant peut le deviner, le forcer par force brute ou le falsifier, il détourne la session. Les ID de session doivent donc être longs et issus d'un CSPRNG, et les jetons doivent utiliser une signature forte avec l'algorithme fixé côté serveur.

Les recruteurs recherchent « HTTP est sans état, les cookies portent un identifiant », le compromis avec état vs sans état (révocation vs scalabilité), et l'exigence de sécurité que l'identifiant soit indevinable.