Pourquoi j’ai arrêté d’utiliser JWT pour mes dashboards admin (et ce que j’utilise à la place)

Le JWT est partout.

La majorité des tutoriels recommandent JWT par défaut pour l’authentification dans les applications web, y compris les dashboards admin.
Je l’ai utilisé pendant des années… jusqu’à ce que je construise de vrais tableaux de bord SaaS et back-offices utilisés quotidiennement par des utilisateurs non techniques.

J’ai rapidement compris que JWT ne résolvait pas le bon problème pour mes projets.

Cet article explique pourquoi JWT est souvent inadapté aux dashboards admin, et ce que j’utilise maintenant à la place.

Les problèmes réels du JWT pour les dashboards admin

JWT n’est pas intrinsèquement dangereux.
Le problème, c’est son implémentation classique.

Dans la plupart des frontends, le JWT est stocké dans :

localStorage

sessionStorage

parfois en mémoire avec un refresh token

Cela pose plusieurs problèmes majeurs.

1. XSS : le risque est réel

Si un attaquant injecte du JavaScript, il peut lire le token et se faire passer pour un utilisateur.

Dans un dashboard admin, c’est inacceptable :

accès aux données utilisateurs

accès à la facturation

accès aux outils internes

2. Les refresh tokens ajoutent de la complexité

Il faut gérer :

expiration des tokens

rotation des refresh tokens

réauthentification silencieuse

multiples cas limites et bugs potentiels

Pour un dashboard privé, cette complexité est inutile.

3. JWT stateless… mais les dashboards ne le sont pas

Les dashboards admin ont souvent besoin de :

sessions côté serveur

vérification de rôles

accès premium

gestion des équipes

révocation instantanée des accès

Le JWT se bat contre ces besoins au lieu de les faciliter.

L’alternative : les cookies HttpOnly

Pour mes dashboards admin, j’utilise désormais l’authentification basée sur les cookies HttpOnly.

Comment ça fonctionne

L’utilisateur se connecte avec email/mot de passe

Le backend crée un cookie HttpOnly

Le frontend ne voit jamais le token

Chaque requête protégée inclut automatiquement le cookie

Exemple de requête frontend :

axios.get("/api/me", { withCredentials: true });

Pas de token à gérer, pas de refresh token, pas de localStorage. Simple et sécurisé.

Pourquoi c’est mieux pour un dashboard admin

1. Protection contre les XSS

Les cookies HttpOnly :

ne sont pas accessibles par JavaScript

sont automatiquement envoyés par le navigateur

réduisent fortement la surface d’attaque

1. Frontend simplifié

Le frontend :

ne gère pas l’état d’authentification

ne manipule aucun token

réagit simplement aux erreurs 401 ou 403

1. Contrôle des rôles côté serveur

Avec cette approche, il est trivial d’appliquer les middlewares :

isAuth

isAdmin

isPremium

Chaque requête est validée côté serveur.

Quand JWT est approprié

JWT n’est pas “mauvais”.
Il est juste souvent mal utilisé.

Il reste pertinent pour :

applications mobiles

APIs publiques

intégrations tierces

microservices stateless

Mais pour un dashboard privé, les cookies HttpOnly sont généralement plus adaptés.

Mon implémentation dans AdminCraft V2

Dans mon starter kit AdminCraft V2 :

Cookies HttpOnly pour l’authentification

Middlewares de rôle (isAuth, isAdmin, isPremium)

Validation serveur à chaque requête

Abonnements Stripe liés aux rôles

Gestion d’équipes via parentUser

Le frontend ne touche jamais aux tokens.
Résultat : code auditable, maintenable et sécurisé.

Résumé

JWT est populaire parce qu’il résout un vrai problème.
Mais tous les projets n’ont pas les mêmes contraintes.

Pour les dashboards admin et back-offices SaaS :

simplicité et sécurité > tendance

moins de code → moins de bugs

moins de risques de sécurité

Voir AdminCraft V2 en action

Le frontend AdminCraft V2 est public et open-source sur GitHub :
👉 GitHub https://github.com/Aymrick97/admincraft-react-admin-dashboard

Le backend Premium (auth, rôles, Stripe, équipes) est disponible séparément :
👉 Gumroad https://admincore.gumroad.com/l/kgevy

💬 Et vous ? Quelle stratégie d’authentification utilisez-vous pour vos dashboards admin ?