Association logique entre points de communication qui établit et maintient de l’état, du contexte ou des identifiants pendant la durée d’une interaction ou d’une série d’interactions, permettant la continuité (p. ex. authentification, numéros de séquence, paramètres négociés) même sur des protocoles de transport sans état.

Principe

Une session regroupe des échanges liés sous des identifiants ou un état partagé afin que les messages suivants puissent être interprétés par rapport au contexte antérieur ; l’état de session peut être conservé aux endpoints, chez des intermédiaires ou dans des stockages distribués et détermine la continuité, l’autorisation et l’association de ressources pendant la durée de la session.

Démonstration

Scénario illustratif → Application web : après authentification réussie, le serveur émet un identifiant de session stocké dans un cookie HTTP ; les requêtes suivantes présentent le cookie, permettant au serveur de récupérer le contexte utilisateur et d’autoriser des actions sans réauthentifier à chaque requête. Conséquence : l’expérience utilisateur est continue et personnalisée pendant la session ; le serveur doit gérer le cycle de vie et le stockage de la session.

Mauvaise application

Interprétation erronée : confondre une session avec une connexion de transport (p. ex. assimiler session HTTP et connexion TCP). Raisonnable car sessions et connexions concernent des interactions « en cours ». Erreur sémantique : ignorer que les sessions peuvent survivre aux connexions de transport et que la continuité de session nécessite une gestion d’état distincte (cookies, tokens, stockages distribués).

Conséquence

Les sessions permettent des fonctionnalités d’état telles que l’authentification, les transactions et la personnalisation ; elles introduisent des enjeux d’échelle et de sécurité (stockage de session, réplication, fixation, détournement, TTL) et imposent des obligations de gestion du cycle de vie (création, renouvellement, expiration, révocation).

Inversion

Qualifications : les conceptions sans état (identifiants basés sur tokens, JWT signés, API idempotentes) évitent volontairement l’état côté serveur pour améliorer l’évolutivité et simplifier la distribution ; les sessions de longue durée posent des risques de sécurité et d’obsolescence et peuvent être contraintes par des exigences réglementaires ou de confidentialité.

Limite

Clairement dans : une session HTTP authentifiée représentée par un magasin d’état côté serveur indexé par un cookie. Cas limite : un jeton porteur (JWT) qui encode des revendications utilisateur et est sans état—il joue un rôle de substitut de session mais avec des sémantiques de révocation différentes. Clairement hors : une requête unique non authentifiée et idempotente qui n’embarque aucun contexte persistant entre invocations.

Tension sémantique

État↔scalabilité/sécurité : maintenir l’état de session favorise des interactions riches et la commodité mais augmente les besoins en ressources serveurs, complique la montée en charge et la réplication, et élargit la surface d’attaque pour le vol ou la fixation de session.

Synthèse

La session est un mécanisme explicite pour porter du contexte sur plusieurs interactions ; elle échange la simplicité sans état contre continuité et capacités, et son usage correct exige une conception délibérée du cycle de vie, du stockage et de la sécurité.