Gestion des tokens JWT dans un SaaS RH : les pièges à éviter

JWT : rappel rapide

Les JWT sont le standard de facto pour l'authentification dans les SaaS. Un token signé qui contient les informations de l'utilisateur (ID, organisation, rôle) et qui peut être vérifié sans appel à la base de données.

C'est simple et performant. Mais cette simplicité cache des pièges que beaucoup d'éditeurs RH découvrent trop tard.

Piège 1 : des tokens qui n'expirent jamais

On le voit régulièrement : des access tokens avec une durée de vie de 30 jours, voire sans expiration du tout. L'argument est toujours le même : "on ne veut pas que l'utilisateur se reconnecte trop souvent".

Le problème : si un token est volé (XSS, interception réseau, poste compromis), l'attaquant a accès pendant 30 jours. Et comme le JWT est auto-suffisant, vous ne pouvez pas le révoquer côté serveur — il reste valide jusqu'à expiration.

Recommandation : access tokens de 15 minutes maximum. Refresh tokens de 7 jours avec rotation à chaque utilisation.

Piège 2 : stocker le JWT dans le localStorage

Le localStorage est accessible par n'importe quel script JavaScript sur la page. Une faille XSS — même dans une dépendance tierce — permet de voler le token.

Recommandation : stockez le refresh token dans un cookie httpOnly, secure, SameSite=Strict. L'access token peut rester en mémoire (variable JavaScript) — il est éphémère de toute façon.

Piège 3 : ne pas vérifier la signature

Ça paraît absurde, mais on l'a déjà vu : le backend décode le JWT sans vérifier la signature. N'importe qui peut modifier le payload (changer le rôle de "user" à "admin") et le backend l'accepte.

Toujours vérifier la signature avec la clé secrète ou la clé publique. Et n'acceptez jamais l'algorithme "none".

Piège 4 : des claims trop larges

Un JWT qui contient le rôle, l'organisation, mais aussi l'email, le nom, le département, le manager... c'est trop. Le JWT est visible par le client (c'est du base64, pas du chiffrement). Limitez-vous aux claims nécessaires pour l'autorisation.

Piège 5 : pas de mécanisme de révocation

Quand un employé quitte l'entreprise, quand un utilisateur signale un vol de session, quand vous détectez une activité suspecte — il faut pouvoir révoquer le token immédiatement.

Avec des access tokens courts (15 min), la fenêtre d'exposition est limitée. Mais pour les refresh tokens, maintenez une liste de révocation (blacklist) en base de données ou en cache Redis.

Checklist JWT pour votre SaaS RH

Si vous n'êtes pas sûr de votre implémentation, un Premier diagnostic CleanIssue permet de vérifier ces points en 48h.