🎟️ Module 1 — Qu'est-ce qu'un JWT ?
Bonne lecture et bon apprentissage ! Junior TSAFACK – 12/09/2026 ⏱️ Temps de lecture estimé : 6 minutes
🤔 Le problème, avant la solution
Section titled “🤔 Le problème, avant la solution”Imaginez un site web avec des millions d’utilisateurs. Vous vous connectez une fois, puis vous naviguez de page en page, vous appelez une API, peut-être même un autre service du même site (le paiement, la messagerie…). À chaque requête, quelqu’un doit répondre à une question simple :
« Qui êtes-vous, et ai-je le droit de vous croire ? »
La méthode historique : une session côté serveur. Au login, le serveur crée un enregistrement (« la session ») dans sa base de données ou en mémoire, et renvoie au navigateur un simple identifiant (un cookie). À chaque requête suivante, le serveur reçoit ce cookie et va rechercher la session correspondante en base pour savoir qui est l’utilisateur.
Ça fonctionne très bien… jusqu’à ce que votre site grossisse. Cinq serveurs derrière un load-balancer ? Il faut que chacun puisse retrouver la session — base partagée, réplication, latence réseau à chaque requête. 😩 Et si un microservice de paiement doit vérifier qui est l’utilisateur, il doit interroger le service d’authentification à chaque appel.
💡 L’idée du JWT
Section titled “💡 L’idée du JWT”Le JSON Web Token (normalisé par la RFC 7519) renverse le problème : au lieu de donner au client un simple numéro de dossier que le serveur doit aller consulter, on lui donne le dossier lui-même, scellé d’une cire infalsifiable.
Session classique : "Voici le ticket n°42, va voir dans mon registre qui c'est."JWT : "Voici tes papiers d'identité, scellés. Montre-les, je vérifie le sceau."Concrètement, un JWT est une petite chaîne de texte qui contient :
- Qui vous êtes (et éventuellement vos rôles/permissions) — en clair, lisible par n’importe qui.
- Une signature cryptographique qui prouve que ces informations n’ont pas été modifiées depuis leur émission par le serveur.
N’importe quel service qui connaît la clé de vérification peut donc contrôler l’identité sans jamais interroger de base de données ni le service d’authentification. C’est ce qui rend les JWT si populaires dans les architectures à API et microservices. 🚀
📍 Où se cachent les JWT ?
Section titled “📍 Où se cachent les JWT ?”Vous en croisez plus souvent que vous ne le pensez :
- OAuth 2.0 / OpenID Connect (« Se connecter avec Google/Microsoft ») : le jeton d’identité échangé est un JWT.
- API REST « stateless » : de nombreuses API (dont beaucoup d’API Odoo modernes, d’API AWS Cognito, ou l’API du serveur MCP vue dans le cours MCP pour Odoo) utilisent des jetons JWT plutôt que des sessions serveur.
- Authentification entre microservices : un service interne fait confiance à un JWT signé par le service d’authentification central, sans avoir à l’interroger à chaque appel.
✅ Ce que vous allez construire dans ce cours
Section titled “✅ Ce que vous allez construire dans ce cours”Ce cours n’est pas que de la théorie : au Module 4, vous allez réellement signer et vérifier des JWT en Python, casser volontairement un token pour voir la vérification échouer, et reproduire (en toute sécurité, à but pédagogique) une vraie faille historique du format — pour comprendre pourquoi les bonnes pratiques du Module 5 existent, pas seulement les retenir par cœur.