Authentification : sessions, JWT et OAuth expliqués
Gérer l’identité des utilisateurs est l’une des tâches les plus sensibles — et les plus mal comprises — du développement web. Sessions, JWT, OAuth : ces termes se mélangent souvent. Clarifions, car une authentification bâclée est une porte ouverte.
Le problème de base : HTTP n’a pas de mémoire
HTTP est sans état : chaque requête est indépendante. Après une connexion, le serveur doit pourtant « se souvenir » de l’utilisateur. Deux grandes stratégies répondent à ce besoin.
Sessions : l’état côté serveur
Le modèle classique : à la connexion, le serveur crée une session (stockée côté serveur) et renvoie un cookie contenant un identifiant de session. À chaque requête, le navigateur renvoie le cookie, le serveur retrouve la session. Simple, éprouvé, révocable instantanément (on supprime la session). Sa contrainte : le serveur doit stocker et partager cet état — un défi quand on multiplie les serveurs.
JWT : l’état côté client
Le JWT (JSON Web Token) inverse la logique : le serveur émet un jeton signé contenant les informations de l’utilisateur, et le client le renvoie à chaque requête. Le serveur n’a rien à stocker : il vérifie la signature, et fait confiance au contenu. Idéal pour les architectures distribuées et les API. Le revers : un JWT est difficile à révoquer avant son expiration, et ne doit jamais contenir de données sensibles (il est lisible).
Sessions ou JWT ?
Application web classique avec un serveur : les sessions restent souvent le choix le plus sûr et le plus simple. API consommée par des clients variés, microservices : le JWT brille. Beaucoup combinent les deux avec des refresh tokens pour concilier sécurité et souplesse.
OAuth : déléguer, pas stocker les mots de passe
OAuth 2.0 répond à une autre question : « se connecter avec Google/GitHub ». C’est un protocole de délégation d’autorisation : l’utilisateur autorise votre app à accéder à certaines infos chez un fournisseur, sans jamais lui donner son mot de passe. Vous n’avez plus à gérer les mots de passe vous-même — un risque de moins.
À retenir
Les sessions gardent l’état côté serveur (simple, révocable) ; les JWT le déportent côté client (scalable, mais difficile à révoquer) ; OAuth délègue la connexion à un tiers de confiance. Choisissez selon votre architecture — et rappelez-vous : en authentification, la simplicité bien maîtrisée bat toujours la complexité mal comprise.
