Chapitre 4.1 — Sessions vs tokens

⏱️ TL;DR — Deux façons de « se souvenir » qu’un utilisateur est connecté. Session serveur : le serveur garde l’état (qui est connecté), le client ne détient qu’un identifiant opaque dans un cookie HttpOnly. Token auto-porté (typiquement un JWT) : l’état est dans le jeton lui-même, côté client, et le serveur le vérifie par signature sans rien stocker. Le token brille pour le stateless et le multi-services ; mais il est difficile à révoquer et souvent mal stocké (localStorage → vol par XSS). Pour une appli web classique, la session serveur avec cookie HttpOnly reste le défaut le plus sûr et le plus simple à révoquer. Choisis selon le besoin, pas selon la mode.

🎯 Objectifs

• Décrire le fonctionnement d’une session serveur et d’un token auto-porté.
• Comparer les deux sur la révocation, le stockage, le passage à l’échelle et l’exposition au XSS/CSRF.
• Savoir pourquoi la session serveur + cookie HttpOnly est souvent le meilleur défaut.
• Choisir l’approche adaptée à un contexte (monolithe, SPA, microservices, mobile).

Session serveur : l’état reste côté serveur

Dans le modèle session, à la connexion, le serveur crée une session (un enregistrement : utilisateur, droits, date…) identifiée par un identifiant aléatoire (CSPRNG). Cet identifiant opaque est envoyé au client dans un cookie ; à chaque requête, le navigateur le renvoie, le serveur retrouve la session et sait qui parle.

Connexion  ->  serveur cree la session #a1b2..., la stocke (mémoire/Redis/DB)
           ->  Set-Cookie: __Host-session=a1b2...; HttpOnly; Secure; SameSite=Lax
Requetes   ->  Cookie: session=a1b2...  ->  serveur lit l'etat de la session
Deconnexion->  serveur SUPPRIME la session #a1b2... -> immediatement invalide

Le cookie ne contient aucune donnée sensible, juste une clé. Tout l’état vit côté serveur, donc sous contrôle : on peut à tout moment invalider une session (déconnexion, changement de mot de passe, compromission détectée) en la supprimant côté serveur.

Token auto-porté : l’état voyage avec le client

Dans le modèle token (souvent un JWT), il n’y a pas d’état côté serveur. À la connexion, le serveur émet un jeton signé contenant les claims (userId, role, exp…). Le client le renvoie à chaque requête ; le serveur vérifie la signature et fait confiance au contenu, sans rien stocker.

Connexion  ->  serveur signe un JWT { userId, role, exp } et le renvoie
Requetes   ->  Authorization: Bearer eyJ...  ->  serveur VERIFIE la signature (stateless)
Deconnexion->  ... le jeton reste techniquement valide jusqu'a exp (probleme !)

L’avantage est le stateless : n’importe quel serveur (ou service) qui connaît la clé de vérification peut valider le jeton, sans base de sessions partagée. Pratique pour du multi-services, des API distribuées, ou quand on veut éviter un store de sessions.

La comparaison qui compte

Le point décisif pour la plupart des applis : la révocation. Une session serveur se coupe instantanément ; un JWT auto-porté reste valable jusqu’à son expiration, ce qui est un vrai problème en cas de compromission ou de déconnexion « qui doit vraiment déconnecter ». Les contournements (blacklist de jetons) réintroduisent de l’état côté serveur — on perd l’argument stateless.

⚠️ Piège — Le combo le plus dangereux, hélas très répandu dans les tutoriels SPA : JWT stocké en localStorage. On cumule les défauts — un XSS vole le jeton en une ligne (localStorage.getItem), et le jeton volé reste valable et irrévocable jusqu’à exp. L’attaquant se connecte alors depuis chez lui, tranquillement. Si tu utilises des JWT, garde-les hors de portée du JS (cookie HttpOnly), et prévois des durées courtes + refresh.

Le bon défaut : session serveur + cookie HttpOnly

Pour une appli web classique (monolithe, SSR, SPA parlant à sa propre API sur le même domaine), le défaut le plus sûr et le plus simple reste :

• session côté serveur (état sous contrôle, révocable),
• identifiant opaque dans un cookie __Host- + HttpOnly + Secure + SameSite=Lax (non volable par XSS, protégé du CSRF),
• rotation de l’identifiant de session à la connexion (contre la session fixation, voir chapitre 4.4).

C’est ce que fournissent nativement les frameworks : les sessions PHP/Symfony, express-session, l’auth par session de la plupart des stacks. On ne prend un JWT que quand un vrai besoin l’exige (services distribués sans store partagé, auth machine-à-machine, mobile).

💡 Réflexe — Ne choisis pas « JWT » par réflexe parce que c’est moderne. Pose-toi : « ai-je vraiment besoin de stateless multi-services ? » Si non (cas le plus courant), la session serveur est plus simple, plus sûre (révocation immédiate, cookie HttpOnly) et suffisante. La bonne question n’est pas « session ou token ? » mais « ai-je un besoin qui justifie de renoncer à la révocation immédiate ? ».

🎯 Côté attaquant — Face à une session opaque en cookie HttpOnly, l’attaquant ne peut ni lire le cookie (XSS bloqué par HttpOnly) ni deviner l’identifiant (CSPRNG). Face à un JWT en localStorage, il lui suffit d’un XSS pour tout rafler — et le jeton volé marche partout, longtemps. Le choix d’architecture change radicalement ce qu’un attaquant obtient d’une même faille. C’est un choix de sécurité, pas juste de confort.

🧭 Sur FormaCampus — Le front app.formacampus.fr et l’API api.formacampus.fr partagent le même domaine parent : FormaCampus utilise donc une session serveur (store Redis), identifiant opaque dans un cookie __Host-session HttpOnly/Secure/SameSite=Lax, rotation à la connexion. Résultat : déconnexion et « déconnecter tous les appareils » sont instantanés, un XSS ne peut pas voler la session, et le CSRF est couvert (SameSite + jeton). Les JWT sont réservés à un usage précis : l’authentification inter-services (API ↔ workers), stateless et à durée courte — jamais exposés au navigateur.

✏️ Exercices

Exercice 1 — Révocation. Un utilisateur signale que son compte est compromis ; tu veux le déconnecter immédiatement de partout. Compare la faisabilité selon qu’on utilise une session serveur ou un JWT auto-porté.

Exercice 2 — Critique le choix. Une SPA stocke un JWT en localStorage et l’envoie en Authorization: Bearer. Le lead dit « pas de risque CSRF, donc c’est plus sûr qu’un cookie ». Réponds de façon nuancée.

🧠 Quiz de révision

Chapitre suivant : Mots de passe & connexion — construire un flux de login qui résiste au bruteforce, au credential stuffing et à l’énumération de comptes.