27 octobre 2026 · 3 min de lecture
Session ou JWT : comment un site vous reconnaît d'une page à l'autre
Session ou JWT : deux façons pour un site de se souvenir que vous êtes connecté. Comment elles fonctionnent, leurs limites, et laquelle choisir.
- sécurité
- bases
Vous vous connectez une fois, puis vous naviguez de page en page sans retaper votre mot de passe. Le site vous reconnaît grâce à une session ou à un JWT : deux manières de garder la preuve que vous êtes bien vous.
Pourquoi il faut un souvenir
Le web « oublie » tout entre deux requêtes : chaque page demandée est traitée comme si le site ne vous avait jamais vu. Pour ne pas redemander le mot de passe à chaque clic, le site vous remet quelque chose à présenter ensuite.
La session : le ticket de vestiaire
Vous déposez votre manteau, on vous donne un ticket numéroté. Le ticket ne dit rien sur vous : c'est le vestiaire qui, dans son registre, sait à qui il correspond.
- Le serveur crée une session, la range dans son registre, et vous envoie un identifiant (souvent dans un cookie).
- À chaque requête, il retrouve votre session grâce à cet identifiant.
- Avantage : pour déconnecter quelqu'un, il suffit de rayer sa ligne du registre.
- Contrepartie : le serveur doit conserver ce registre.
Le JWT : le badge scellé
Le JWT (JSON Web Token) fonctionne comme un badge qui contient déjà vos informations (qui vous êtes, jusqu'à quand), avec un sceau que seul le serveur sait apposer. Pour le vérifier, le serveur contrôle le sceau : pas besoin de registre.
- Avantage : pratique quand plusieurs services doivent vous reconnaître sans tous consulter la même base.
- Contrepartie : tant qu'il n'a pas expiré, le badge reste valable. Le révoquer avant l'heure est plus compliqué.
- Attention : le contenu est signé, pas caché. N'y mettez jamais d'information confidentielle.
Les bons réflexes, quel que soit le choix
- Donnez une durée de vie courte au badge ou à la session, et renouvelez-la.
- Stockez-le dans un cookie protégé (marqué
HttpOnly, donc illisible par les scripts de la page), plutôt que dans un endroit que n'importe quel script peut lire. - Servez tout en HTTPS.
- Gardez le secret qui scelle les JWT côté serveur, comme n'importe quelle clé.
Lequel choisir ?
Pour un produit avec une seule application et un seul serveur, la session est le plus souvent la plus simple et la plus facile à révoquer. Le JWT a son intérêt quand l'architecture l'exige. Les deux se configurent mal très facilement : le choix compte moins que le soin apporté.
À retenir
Session : le serveur se souvient de vous. JWT : vous portez votre preuve. Dans les deux cas, durée courte, cookie protégé, HTTPS.
Et pour votre produit ?
Beaucoup d'applications générées vite, ou héritées, gèrent la connexion à leur façon, sans que personne ne l'ait relue. Un audit de votre application regarde justement comment vos utilisateurs sont reconnus et protégés. On peut en parler lors d'un échange de 30 minutes.
À lire aussi : le hachage de mot de passe, OAuth, ou « se connecter avec Google » et le XSS.