Sessions et cookies : maintenir un utilisateur connecté

Ce que le cours sur HTTP a déjà posé

Le chapitre sur les cookies et sessions du cours HTTP a expliqué le mécanisme de base : un cookie de session permet à un serveur de reconnaître un visiteur d’une requête à l’autre, sur un protocole qui ne conserve autrement aucune mémoire. Ce chapitre va plus loin : le cycle de vie complet d’une session, pas seulement son principe.

Le cycle de vie d’une session, étape par étape

1. Visite anonyme     : une session est deja creee, non authentifiee
2. Connexion reussie   : l'identifiant de session EST REGENERE (jamais reutilise)
3. Session active      : chaque requete verifie que l'identifiant reste valide
4. Deconnexion         : la session est invalidee cote serveur, pas juste effacee cote client
5. Expiration          : au-dela d'une duree fixe, la session devient invalide meme sans deconnexion explicite

Pourquoi régénérer l’identifiant à la connexion

C’est le point le plus souvent oublié. Si l’identifiant de session reste identique avant et après la connexion, un attaquant qui parvient à imposer à l’avance un identifiant connu de lui (voir le chapitre sur la fixation de session, en fin de cours) n’a plus qu’à attendre que la victime se connecte sous ce même identifiant pour en hériter automatiquement.

Pourquoi une session doit quand même expirer

Même correctement protégée (HttpOnly, Secure, SameSite, vus dans le cours sur HTTP), une session qui ne connaît aucune limite de durée reste une fenêtre d’exploitation permanente si son identifiant est un jour compromis : appareil partagé oublié, cookie intercepté, ou tout simplement un utilisateur qui ne se déconnecte jamais explicitement. Une expiration, même généreuse, borne cette fenêtre dans le temps.