Concepts expliqués ~1 min de lecture
Pourquoi une liste de révocation complète un JWT
Un JWT signé peut rester valide après une déconnexion. Le point faible n’est pas la signature, c’est l’absence de révocation native.
Un JWT signé garantit surtout que le token a bien été émis par le serveur et que son contenu n’a pas été altéré. En pratique, si la signature est correcte et que exp n’est pas dépassé, le token est généralement accepté.
La limite vient de là: un JWT n’a pas de révocation native. Une déconnexion, une désactivation de compte ou un changement de rôle n’invalident pas automatiquement les tokens déjà émis. Le token transporte un état figé au moment de sa création.
Pour reprendre la main, il faut réintroduire un contrôle côté serveur. Les options courantes sont une denylist, une version de session stockée en base, ou des access tokens à courte durée de vie combinés à un mécanisme de refresh. Le choix dépend du niveau de risque et de l’architecture.
Exemple: un JWT porte role=admin avec une expiration à une heure. Si le rôle change après l’émission et que l’API ne vérifie que la signature et exp, le token peut continuer à donner l’accès admin jusqu’à son expiration.
