JWT
2 tools
Fondamentaux de la sécurité Web
La sécurité Web est la pratique consistant à protéger les applications Web et les API contre les accès non autorisés, les violations de données et les attaques.
Les JSON Web Tokens (JWT) sont le mécanisme d'authentification sans état dominant dans le développement Web moderne.
JSON Web Tokens (JWT)
Un JWT est un moyen compact et sécurisé pour les URL de représenter des revendications entre deux parties. Il se compose de trois parties encodées en Base64url séparées par des points.
Les trois parties d'un JWT
Contient les métadonnées du token : l'algorithme de signature (alg) et le type de token (typ).
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9{
"alg": "HS256",
"typ": "JWT"
}Contient les revendications : déclarations sur l'utilisateur. Les données du payload ne sont PAS chiffrées, seulement signées.
eyJzdWIiOiJ1c2VyXzEyMyIsInJvbGUiOiJhZG1pbiIsImV4cCI6MTcxNzIwMDAwMH0{
"sub": "user_123",
"role": "admin",
"exp": 1717200000
}Une signature cryptographique sur l'en-tête et le payload encodés. La vérification garantit que le token n'a pas été altéré.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5cHMACSHA256( base64url(header) + "." + base64url(payload), secret )
Revendications JWT standard
La spécification JWT définit des noms de revendications standard pour garantir l'interopérabilité :
| Revendication | Nom | Description |
|---|---|---|
| iss | Issuer | Identifie le principal qui a émis le token |
| sub | Subject | Identifie le principal qui est le sujet du token (ex. : ID utilisateur) |
| aud | Audience | Identifie les destinataires pour lesquels le token est destiné |
| exp | Expiration | Timestamp Unix après lequel le token ne doit plus être accepté |
| nbf | Not Before | Timestamp Unix avant lequel le token ne doit pas être accepté |
| iat | Issued At | Timestamp Unix auquel le token a été émis |
| jti | JWT ID | Identifiant unique du token, utilisé pour prévenir les attaques par rejeu |
Algorithmes de signature
L'algorithme de signature est déclaré dans l'en-tête JWT. Le bon choix est crucial pour la sécurité :
HS256 / HS384 / HS512Symétrique (HMAC)Utilise une clé secrète partagée pour la signature et la vérification.
RS256 / RS384 / RS512Asymétrique (RSA)Utilise une clé privée pour signer et une clé publique pour vérifier. La clé privée ne quitte jamais le serveur d'authentification.
ES256 / ES384 / ES512Asymétrique (ECDSA)Comme RSA mais avec des clés plus petites et une signature plus rapide.
"alg": "none"Non signé — DANGEREUXAucune signature. Un token avec alg:none n'a aucune garantie d'intégrité.
Flux d'authentification
- 1.L'utilisateur envoie son nom d'utilisateur et mot de passe au point de terminaison de connexion
- 2.Le serveur valide les identifiants contre la base de données utilisateurs
- 3.Le serveur signe un JWT avec les revendications utilisateur et l'expiration
- 4.Le client stocke le JWT (localStorage, cookie ou mémoire)
- 5.Le client envoie le JWT dans l'en-tête Authorization: Bearer pour les requêtes suivantes
- 1.Le client redirige l'utilisateur vers le serveur d'autorisation avec le défi de code
- 2.L'utilisateur s'authentifie et autorise l'application cliente
- 3.Le serveur d'authentification redirige avec un code d'autorisation à usage unique
- 4.Le client échange le code + vérificateur contre des tokens d'accès et de rafraîchissement
- 5.Le client utilise le token d'accès pour les appels API ; le token de rafraîchissement pour le renouvellement
Vulnérabilités JWT courantes
Les JWT sont sécurisés lorsqu'ils sont correctement implémentés. Voici les erreurs d'implémentation les plus courantes :
Certaines bibliothèques acceptent les tokens avec alg:none. Un attaquant peut modifier le payload et définir alg sur none pour forger n'importe quel JWT.
Si une bibliothèque est censée vérifier RS256 mais accepte HS256, un attaquant peut signer un token en utilisant la clé publique comme secret HMAC.
Un JWT sans revendication exp permet une utilisation indéfinie des tokens. Toujours définir des durées d'expiration courtes.
Les payloads JWT sont encodés en Base64, pas chiffrés. Ne jamais stocker de mots de passe ou autres secrets dans les revendications JWT.
Les JWT signés HMAC avec des secrets courts ou prévisibles peuvent être forcés hors ligne.
Accepter des JWT sans vérifier la signature fait entièrement confiance au payload. Toujours vérifier la signature avant de faire confiance à une revendication.
Questions fréquentes
Les JWT standard (JWS) sont signés mais PAS chiffrés. Le payload est encodé en Base64url, facilement décodable.
Les tokens d'accès doivent être de courte durée : 5 à 60 minutes est typique. Utilisez des tokens de rafraîchissement pour obtenir de nouveaux tokens d'accès.
Les cookies HttpOnly sont l'option la plus sécurisée — inaccessibles au JavaScript, empêchant le vol par XSS.
Pas sans état côté serveur. Solutions : délais d'expiration courts, liste de blocage de tokens (Redis).
Les cookies de session stockent un ID de session aléatoire ; le serveur recherche les données de session. Les JWT sont autonomes — le serveur valide la signature sans requête de base de données.
Le minimum : sub (ID utilisateur), exp (expiration) et iat (émis le). Gardez les payloads petits.
RS256 (asymétrique) est préférable pour la plupart des systèmes de production car seul le serveur d'authentification a besoin de la clé privée.
PKCE est une extension du flux de code d'autorisation OAuth2 qui empêche les attaques d'interception de code. Obligatoire pour les clients publics (SPA, applications mobiles).