Quelle est la différence entre JWT et une session classique ?

Une session classique stocke les données côté serveur et utilise un cookie d'identifiant. Le JWT est un token autonome signé contenant toutes les informations nécessaires, ce qui le rend stateless : le serveur n'a rien à stocker. C'est idéal pour les API REST consommées par des applications mobiles ou des SPA.

Combien de temps un token JWT doit-il rester valide ?

Un access token JWT devrait avoir une durée de vie courte, idéalement entre 5 et 15 minutes. Pour éviter de redemander les identifiants à l'utilisateur, on utilise un refresh token (valide 7 à 30 jours) stocké de manière sécurisée, qui permet de générer un nouvel access token.

Sécuriser une API REST : bonnes pratiques et JWT en 2025

Pourquoi la sécurité de votre API REST est critique

En 2024, les API représentaient le vecteur d’attaque n°1 selon le rapport OWASP API Security Top 10. Et pour cause : une API exposée sans protection, c’est une porte grande ouverte sur vos données, vos utilisateurs et votre infrastructure.

Que vous développiez une application mobile, un SaaS ou un site e-commerce sous Prestashop, votre API REST mérite une sécurité rigoureuse. Voici les bonnes pratiques essentielles et un focus sur JWT, le standard d’authentification le plus utilisé.

Les fondamentaux : le socle de sécurité minimal

Avant même de parler d’authentification, certaines mesures sont non négociables :

HTTPS obligatoire : 100 % de vos échanges doivent être chiffrés. Un token transmis en HTTP clair est un token volé.
Validation des entrées : chaque paramètre reçu doit être typé, limité en taille et assaini. C’est la première défense contre les injections SQL et XSS.
Rate limiting : limitez le nombre de requêtes par IP (ex. : 100 requêtes/minute). Cela bloque les attaques par force brute et les abus.
CORS configuré strictement : n’autorisez que les domaines légitimes à interroger votre API.
En-têtes de sécurité : X-Content-Type-Options, X-Frame-Options, Strict-Transport-Security.

Ces cinq points couvrent déjà environ 60 % des vulnérabilités courantes sur les API REST.

JWT : comprendre le mécanisme en 30 secondes

Le JSON Web Token (JWT) est un standard ouvert (RFC 7519) qui permet d’échanger des informations de manière vérifiable entre deux parties. Un JWT se compose de trois parties encodées en Base64, séparées par des points :

header.payload.signature

Fonctionnement type

L’utilisateur envoie ses identifiants (login/mot de passe)
Le serveur vérifie et génère un JWT signé avec une clé secrète
Le client stocke le token et l’envoie dans chaque requête via le header Authorization: Bearer <token>
Le serveur vérifie la signature à chaque requête — sans base de données

C’est ce qu’on appelle l’authentification stateless : le serveur ne stocke aucune session. Résultat : performances accrues et scalabilité horizontale simplifiée, notamment sur des architectures cloud comme AWS.

Les bonnes pratiques JWT à respecter impérativement

Choisir le bon algorithme de signature

Utilisez RS256 (asymétrique) pour les architectures distribuées ou HS256 (symétrique) pour les cas simples. Ne laissez jamais l’algorithme none activé — c’est une faille classique exploitée dans plus de 17 % des attaques ciblant JWT selon Auth0.

Limiter la durée de vie des tokens

Type de token	Durée recommandée	Stockage
Access token	5 à 15 minutes	Mémoire (variable JS)
Refresh token	7 à 30 jours	Cookie HttpOnly Secure

Un access token à durée de vie longue (24h ou plus) est un risque majeur en cas de vol.

Ne jamais stocker de données sensibles dans le payload

Le payload JWT est encodé, pas chiffré. N’y placez jamais de mot de passe, de numéro de carte ou de données personnelles sensibles. Limitez-vous à l’identifiant utilisateur et aux rôles.

Implémenter la révocation

Le JWT étant stateless, il est difficile à révoquer. Deux solutions courantes :

Blacklist en Redis : stockez les tokens révoqués avec un TTL égal à leur expiration
Rotation de refresh tokens : chaque utilisation du refresh token en génère un nouveau et invalide l’ancien

Erreurs fréquentes à éviter

Transmettre le JWT dans l’URL (visible dans les logs serveur)
Stocker l’access token dans le localStorage (vulnérable aux attaques XSS)
Ignorer la vérification de la signature côté serveur
Utiliser une clé secrète faible (moins de 256 bits)

Chez Lueur Externe, agence web spécialisée depuis 2003 et certifiée AWS Solutions Architect, nous auditons régulièrement des API qui cumulent deux ou trois de ces erreurs. La correction est souvent simple, mais l’impact d’une exploitation peut être dévastateur.

Conclusion : ne laissez pas votre API sans protection

Sécuriser une API REST n’est pas un luxe — c’est une obligation technique et légale (RGPD, directive NIS2). HTTPS, validation des entrées, rate limiting et une implémentation JWT rigoureuse constituent le minimum requis en 2025.

Si vous avez le moindre doute sur la sécurité de votre API, les experts Lueur Externe peuvent réaliser un audit complet et vous accompagner dans la mise en conformité. Mieux vaut prévenir qu’être la prochaine fuite de données.