📝 BLOG

JSON Web Token (JWT) : Guide d'Authentification et de Sécurité

JSON Web Token (JWT) est un token standard ouvert utilisé pour l'authentification et l'échange d'informations dans les applications web. Ce guide couvre la structure JWT, les cas d'usage, les risques de sécurité et les bonnes pratiques.

Mise à jour :

Préparé par: Gsetsoft

JSON Web Token (JWT) : Guide d'Authentification et de Sécurité

Qu'est-ce que JWT ?

JWT (JSON Web Token) est un format de token compact et sûr pour les URL, défini dans RFC 7519, utilisé pour l'échange sécurisé d'informations entre parties.

JWT se compose de trois parties : Header, Payload et Signature. Ces trois parties sont séparées par des points (.) : xxxxx.yyyyy.zzzzz

Fournit une authentification sans état. Au lieu de stocker les données de session dans une base de données, le serveur envoie le token au client. Le client envoie le token à chaque requête.

Cas d'usage : Authentification API, SSO (Single Sign-On), authentification entre microservices, autorisation d'applications mobiles.

Structure JWT

Header : Contient le type de token (JWT) et l'algorithme de signature (HS256, RS256, ES256). Encodé en Base64URL.

Payload : Contient les claims. Registered claims (iss, sub, aud, exp, nbf, iat, jti), public claims et private claims. Encodé en Base64URL.

Signature : Le header et payload encodés en Base64URL sont joints par un point et signés avec une clé secrète. HS256 utilise HMAC-SHA256, RS256 utilise RSA-SHA256.

Exemple : eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Flux d'utilisation JWT

1. L'utilisateur envoie une requête à l'endpoint de login avec nom d'utilisateur et mot de passe.

2. Le serveur vérifie les identifiants et crée un JWT. Le token est retourné dans le body de la réponse ou en cookie.

3. Le client stocke le token dans localStorage ou cookie httpOnly.

4. Dans les requêtes suivantes, le client envoie JWT comme Bearer token dans le header Authorization : Authorization: Bearer <token>

5. Le serveur valide le token (vérification de signature et d'expiration). Si valide, traite la requête ; si invalide, retourne 401 Unauthorized.

Risques de sécurité

Vol de token : Le token dans localStorage peut être volé via une attaque XSS. Utilisez un cookie httpOnly pour réduire le risque XSS.

Durée de vie du token : Access token de courte durée (15-30 min) + refresh token de longue durée (7-30 jours). Rotatez le refresh token à chaque utilisation.

Confusion d'algorithme : Algorithme 'none' ou passage RS256→HS256. Définissez l'algorithme comme constante côté serveur, ne le prenez pas du token.

Données sensibles : Le payload JWT est encodé en Base64, pas chiffré. Ne mettez pas de données sensibles (mot de passe, carte de crédit) dans le payload.

Taille du token : JWT est plus grand qu'un cookie de session. Envoyé à chaque requête. Gardez le payload minimal.

Bonnes pratiques

Tokens de courte durée : Access token 15-30 minutes, refresh token 7-30 jours. Les tokens expirés deviennent automatiquement invalides.

Cookie httpOnly + Secure + SameSite : Stockez le token dans un cookie httpOnly. JavaScript ne peut pas y accéder (protection XSS). Secure (HTTPS uniquement). SameSite (protection CSRF).

Rotation de token : Le refresh token est renouvelé à chaque utilisation. L'ancien refresh token devient invalide. Limite l'accès de l'attaquant en cas de vol de token.

Blacklist/révocation : Utilisez une blacklist pour révoquer les tokens. Stockez les tokens révoqués dans Redis. Utilisez pour logout et incidents de sécurité.

Algorithme : RS256 (asymétrique) recommandé pour la production. Signez avec la clé privée, vérifiez avec la clé publique. HS256 (symétrique) uniquement pour un seul service.

Validation : Vérifiez la signature, l'issuer (iss), l'audience (aud), l'expiration (exp) à chaque requête. Assurez-vous que toutes les vérifications passent avant de faire confiance au token.

JWT vs Authentification basée sur session

JWT : Sans état, scaling horizontal facile, idéal pour les microservices, taille de token grande, difficile à révoquer.

Session : Avec état, nécessite un stockage côté serveur, nécessite sticky session ou shared store pour le scaling horizontal, taille de token petite, facile à révoquer.

Critères de sélection : Architecture microservices → JWT. Application monolithique → Session. App mobile → JWT. Exigence de haute sécurité → Session + JWT hybride.

Approche hybride : JWT de courte durée (access token) + session store (refresh token). Combine les avantages des deux.

Votre choix de confidentialité

Les cookies essentiels assurent sécurité et sessions. Les visites de base sont comptées ; votre accord active des analyses supplémentaires. Politique de cookies