JWT
Définition
JSON Web Token. Format de jeton signé qui contient l'identité d'un utilisateur. Permet à un client de prouver son identité à chaque appel API sans repasser par la base de données.
Comment ça marche
Un JWT (JSON Web Token) est un jeton signé qui contient des informations sur l'utilisateur sous forme d'un objet JSON encodé en base64. Il se compose de trois parties séparées par des points : un header (type et algorithme), un payload (les claims, comme user_id, role, exp), et une signature (calculée à partir du header + payload + clé secrète). Le serveur signe le JWT à la création, le client le stocke (cookie ou localStorage), puis l'envoie à chaque requête API. Le serveur vérifie la signature en quelques millisecondes : si elle est valide, l'identité est confirmée sans aller chercher la session en base de données.
À quoi ça sert
Le JWT brille dans les architectures stateless et distribuées. Sur un SaaS multi-service, chaque microservice vérifie le JWT localement sans consulter une session centrale, ce qui simplifie le scaling. Sur un Supabase, le JWT issu de l'auth est utilisé par PostgREST et la RLS pour identifier l'utilisateur sur chaque requête. Sur une app mobile + API, le JWT remplace le système de session cookie classique. Sur des intégrations B2B, on signe des JWT pour authentifier des appels webhook ou des accès temporaires. C'est le standard moderne pour transporter l'identité entre services.
Les algorithmes
Deux familles principales. HS256 (HMAC SHA-256) utilise une clé secrète symétrique : qui signe peut aussi vérifier. Simple, rapide, parfait pour un monolithe ou un duo client-serveur. RS256 (RSA SHA-256) utilise une paire de clés asymétriques : la clé privée signe, la clé publique vérifie. Indispensable quand plusieurs services indépendants doivent vérifier le JWT sans connaître le secret de signature. Pour un Supabase ou une auth fédérée (Auth0, Clerk), c'est RS256 par défaut. On évite à tout prix l'algorithme "none" (pas de signature), source de la fameuse faille JWT alg=none des années 2010.
Les limites
Le JWT n'est pas chiffré : son contenu est lisible par n'importe qui en base64. On ne met jamais de données sensibles dedans (mot de passe, numéro de carte, données médicales). Le JWT n'est pas révocable nativement : si on veut révoquer un token avant son expiration, il faut maintenir une blacklist côté serveur, ce qui casse la promesse stateless. On compense avec des expirations courtes (15 minutes) et un système de refresh tokens stockés en base, eux révocables. Le JWT est lourd (souvent 500 octets à 1 ko) : envoyé à chaque requête, ça pèse plus qu'un cookie de session standard.
Quand l'utiliser
On choisit JWT pour : architectures avec plusieurs services indépendants qui doivent partager l'identité, APIs publiques consommées par mobile ou tiers, intégrations Supabase et Auth0 qui en font la base, signatures de webhooks et de liens temporaires (réinitialisation de mot de passe, magic link, lien d'invitation). Pour un site web classique avec un seul backend Next.js, un simple cookie de session HTTP-only stocké côté serveur reste plus sûr et plus simple : pas de JWT à révoquer, pas de payload visible, refresh automatique. Le JWT n'est pas une obligation moderne, c'est un outil adapté à certains cas.
Les pièges à éviter
Stocker le JWT en localStorage l'expose au XSS : tout JavaScript malveillant injecté peut le voler. On préfère les cookies HTTP-only + SameSite=strict pour les apps web. Ne jamais accepter un JWT sans vérifier sa signature : c'est arrivé dans des produits sérieux, avec des conséquences catastrophiques. Vérifier systématiquement l'expiration (claim exp), l'audience (aud), l'émetteur (iss). Ne pas faire confiance au claim role sans le valider côté serveur à chaque requête sensible. Utiliser des bibliothèques éprouvées (jose, jsonwebtoken) plutôt que d'implémenter la vérification soi-même. Et changer la clé de signature périodiquement, en supportant deux clés en transition.
Les bonnes pratiques
Expiration courte (15 minutes à 1 heure) pour limiter la fenêtre d'attaque en cas de vol. Refresh token longue durée (7 à 30 jours) stocké en base et révocable. Cookie HTTP-only + Secure + SameSite pour les apps web. Rotation périodique de la clé de signature (tous les 6 mois minimum). Vérification systématique côté serveur des claims critiques (user_id, role, organization_id). Signature avec RS256 dès qu'on a plus d'un service consommateur. Et un mécanisme de logout serveur qui ajoute le JWT à une blacklist temporaire (jusqu'à l'expiration naturelle) pour les comptes compromis.