Module 3 — Le flux d'authentification complet

Bonne lecture et bon apprentissage ! Junior TSAFACK – 12/09/2026 Temps de lecture estimé : 5 minutes

Maintenant que vous savez ce que contient un JWT (Module 2), voyons son cycle de vie complet — depuis le login jusqu’à la dernière requête de la journée.

┌──────────┐                                  ┌──────────┐
│  Client  │ ──── POST /login (email+mdp) ──► │ Serveur  │
└──────────┘                                  └──────────┘
                                                    │
                                          Vérifie le mot de passe
                                          (hash + comparaison)
                                                    │
                                          Génère un JWT signé,
                                          contenant sub, role, exp
                                                    │
┌──────────┐                                       ▼
│  Client  │ ◄──────── { "token": "eyJhbG..." } ───┘
└──────────┘

Le serveur ne stocke rien. Contrairement à une session classique, aucune ligne n’est créée dans une table sessions : toute l’information nécessaire est dans le token lui-même, scellée par la signature.

Étape 2 — Le client garde le token

Le client (une application web, mobile, ou un autre service) conserve ce token quelque part — nous verrons au Module 5 que où on le stocke a d’énormes conséquences de sécurité.

Étape 3 — Chaque requête l’accompagne

┌──────────┐   GET /api/factures                            ┌──────────┐
│  Client  │   Authorization: Bearer eyJhbG...           ──►│ Serveur  │
└──────────┘                                                └──────────┘
                                                                  │
                                                    1. Decoupe header.payload.signature
                                                    2. Recalcule la signature avec sa cle
                                                    3. Compare : identique ?
                                                    4. Verifie exp (pas expire ?)
                                                    5. Lit "sub" et "role" -> autorise ou non
                                                                  │
┌──────────┐                                                     ▼
│  Client  │ ◄──────────────── 200 OK { factures } ──────────────┘
└──────────┘

Le point essentiel : aucun aller-retour vers une base de données ou un service tiers n’est nécessaire pour valider l’identité. C’est une opération purement locale et rapide (quelques microsecondes de calcul cryptographique), ce qui est tout l’intérêt des JWT dans une architecture distribuée avec plusieurs services.

Session classique :  Client -> Serveur A -> [va interroger la base/le service d'auth] -> reponse
JWT                :  Client -> Serveur A -> [verifie localement, sans reseau] -> reponse

Étape 4 — L’expiration et le refresh

Un JWT porte presque toujours un claim exp (voir Module 2) : passé ce délai, il est automatiquement rejeté (nous le vérifierons pour de vrai au Module 4). Comme on ne peut pas « révoquer » un JWT déjà émis (il reste valide jusqu’à son expiration, quoi qu’il arrive — voir Module 5), la pratique courante est de garder sa durée de vie courte (minutes) et d’utiliser un second jeton, le refresh token, pour en obtenir un nouveau sans redemander le mot de passe :

┌──────────┐  access_token expire !                          ┌──────────┐
│  Client  │  POST /refresh { refresh_token }             ──►│ Serveur  │
└──────────┘                                                 └──────────┘
                                                                  │
                                                    Verifie le refresh_token
                                                    (souvent stocke en base,
                                                     lui, revocable)
                                                                  │
┌──────────┐                                                     ▼
│  Client  │ ◄────── nouveau access_token (JWT frais) ───────────┘
└──────────┘

Le refresh token, lui, est généralement une simple chaîne aléatoire stockée côté serveur (donc révocable à tout moment) — c’est le compromis classique entre la rapidité des JWT et le besoin de pouvoir couper l’accès d’un utilisateur immédiatement.

À retenir

Le JWT est émis une fois au login, puis voyage dans l’en-tête Authorization: Bearer ... de chaque requête.
La vérification est locale, sans base de données — c’est la raison d’être du format.
Un JWT ne se « déconnecte » pas vraiment avant son expiration : le couple access token court + refresh token révocable est le compromis standard.

Prochaine étape

Assez de théorie — place à la pratique : au Module 4, nous allons signer, vérifier, casser et forger de vrais tokens en Python.