{"id":61,"date":"2026-06-11T16:24:02","date_gmt":"2026-06-11T16:24:02","guid":{"rendered":"https:\/\/shattered.io\/fr\/2026\/06\/11\/authentification-jwt-nodejs\/"},"modified":"2026-06-11T16:24:02","modified_gmt":"2026-06-11T16:24:02","slug":"authentification-jwt-nodejs","status":"publish","type":"post","link":"https:\/\/shattered.io\/fr\/2026\/06\/11\/authentification-jwt-nodejs\/","title":{"rendered":"Authentification JWT en Node.js : 12 \u00e9tapes [2026]"},"content":{"rendered":"\n

Le jeton JWT (JSON Web Token) est devenu le standard de fait pour l’authentification sans \u00e9tat dans les API modernes. En 2026, la biblioth\u00e8que jsonwebtoken<\/code> reste la r\u00e9f\u00e9rence c\u00f4t\u00e9 Node.js avec sa version stable 9.0.3<\/strong>, que Snyk classe sans vuln\u00e9rabilit\u00e9 connue. Ce tutoriel vous guide en 12 \u00e9tapes pour construire un syst\u00e8me d’authentification JWT complet, s\u00e9curis\u00e9 et pr\u00eat pour la production, avec access token<\/code>, refresh token<\/code>, hachage de mot de passe et middleware de v\u00e9rification.<\/p>\n\n\n\n

Comptez environ 45 minutes pour le suivre de bout en bout. \u00c0 la fin, vous disposerez d’un projet Express fonctionnel, d’une compr\u00e9hension claire des algorithmes HS256<\/code>, RS256<\/code> et ES256<\/code>, et d’une liste de pi\u00e8ges \u00e0 \u00e9viter qui font tomber la majorit\u00e9 des impl\u00e9mentations amateurs. Tout le code est test\u00e9 sur Node.js 22 LTS.<\/p>\n\n\n\n

JWT en 2026 : pourquoi l’authentification par jeton domine<\/h2>\n\n\n\n

Un JWT transporte des informations v\u00e9rifiables entre deux parties sous forme d’objet JSON sign\u00e9. Contrairement aux sessions classiques, le serveur n’a rien \u00e0 stocker : le jeton lui-m\u00eame contient les revendications (claims) sur l’utilisateur, et la signature garantit qu’il n’a pas \u00e9t\u00e9 falsifi\u00e9. Cette nature sans \u00e9tat<\/strong> explique son succ\u00e8s dans les architectures distribu\u00e9es, les microservices et les applications mobiles, o\u00f9 conserver une session c\u00f4t\u00e9 serveur sur chaque n\u0153ud co\u00fbte cher.<\/p>\n\n\n\n

La sp\u00e9cification officielle, la RFC 7519<\/a>, d\u00e9finit la structure du jeton. Une seconde RFC, la RFC 8725 (JWT Best Current Practices)<\/a>, publi\u00e9e par l’IETF, \u00e9num\u00e8re les contre-mesures contre les attaques connues. Lire ces deux documents change la fa\u00e7on dont vous \u00e9crivez votre code : on comprend vite que JWT n’est pas magique et qu’une mauvaise configuration ouvre des failles graves.<\/p>\n\n\n\n

Le d\u00e9bat JWT contre sessions revient sans cesse. Les sessions sont avec \u00e9tat<\/strong> : le serveur garde une trace de chaque connexion, ce qui rend la r\u00e9vocation imm\u00e9diate triviale. Les JWT sont sans \u00e9tat : ils passent \u00e0 l’\u00e9chelle sans base de donn\u00e9es de sessions, mais r\u00e9voquer un jeton avant son expiration demande un effort suppl\u00e9mentaire (liste de r\u00e9vocation, rotation des refresh tokens). Ce tutoriel adopte une approche hybride qui combine le meilleur des deux mondes.<\/p>\n\n\n\n

Un point essentiel souvent mal compris : la charge utile d’un JWT n’est pas chiffr\u00e9e<\/strong>. Elle est seulement encod\u00e9e en Base64URL, donc lisible par quiconque intercepte le jeton. La signature emp\u00eache la modification, pas la lecture. Ne placez jamais de mot de passe, de num\u00e9ro de carte ou de donn\u00e9e sensible dans le payload. Si vous avez besoin de confidentialit\u00e9, il faut chiffrer le jeton (JWE), un sujet que nous abordons dans les astuces avanc\u00e9es.<\/p>\n\n\n\n

Pr\u00e9requis et versions logicielles requises<\/h2>\n\n\n\n

Avant de coder, v\u00e9rifiez votre environnement. Les versions ci-dessous sont celles test\u00e9es pour ce guide. Pour les composants o\u00f9 une version exacte n’est pas critique, la derni\u00e8re version stable convient parfaitement.<\/p>\n\n\n\n

Composant<\/th>Version recommand\u00e9e<\/th>R\u00f4le dans le projet<\/th><\/tr><\/thead>
Node.js<\/td>22 LTS (ou derni\u00e8re LTS)<\/td>Environnement d’ex\u00e9cution serveur<\/td><\/tr>
npm<\/td>10 ou sup\u00e9rieur<\/td>Gestionnaire de paquets<\/td><\/tr>
jsonwebtoken<\/td>9.0.3<\/td>Signature et v\u00e9rification des JWT<\/td><\/tr>
express<\/td>derni\u00e8re version 4.x ou 5.x<\/td>Serveur HTTP et routage<\/td><\/tr>
bcrypt<\/td>derni\u00e8re version stable<\/td>Hachage des mots de passe<\/td><\/tr>
argon2<\/td>derni\u00e8re version stable<\/td>Alternative moderne \u00e0 bcrypt<\/td><\/tr>
dotenv<\/td>derni\u00e8re version stable<\/td>Gestion des variables d’environnement<\/td><\/tr>
cookie-parser<\/td>derni\u00e8re version stable<\/td>Lecture des cookies httpOnly<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

V\u00e9rifiez votre version de Node.js avec une seule commande. Si elle est inf\u00e9rieure \u00e0 18, mettez \u00e0 jour : les versions plus anciennes manquent du module crypto.webcrypto<\/code> stable et de plusieurs correctifs de s\u00e9curit\u00e9. La liste officielle des versions LTS se trouve sur nodejs.org<\/a>.<\/p>\n\n\n\n

node --version\n# Sortie attendue : v22.x.x (ou une version LTS plus r\u00e9cente)\n\nnpm --version\n# Sortie attendue : 10.x.x ou sup\u00e9rieur<\/code><\/pre>\n\n\n\n
C\u00f4t\u00e9 connaissances, vous devez \u00eatre \u00e0 l’aise avec JavaScript asynchrone (async\/await<\/code>), les requ\u00eates HTTP et la notion de middleware Express. Une compr\u00e9hension de base des signatures num\u00e9riques<\/a> et des fonctions de hachage cryptographiques<\/a> aide \u00e9norm\u00e9ment, car JWT repose enti\u00e8rement sur ces deux primitives.<\/p>\n\n\n\n
Anatomie d’un JWT : header, payload et signature<\/h2>\n\n\n\n
Un JWT se compose de trois segments s\u00e9par\u00e9s par des points : header.payload.signature<\/code>. Chaque segment est encod\u00e9 en Base64URL. Un jeton r\u00e9el ressemble \u00e0 ceci (raccourci pour la lisibilit\u00e9) :<\/p>\n\n\n\n
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjMiLCJyb2xlIjoiYWRtaW4iLCJleHAiOjE3ODA1MDAwMDB9.dQw4w9WgXcQ_signature_tronquee<\/code><\/pre>\n\n\n\n
Le header : type et algorithme<\/h3>\n\n\n\n
Le premier segment d\u00e9crit le type du jeton et l’algorithme de signature. D\u00e9cod\u00e9, il donne un objet JSON minimal. Le champ alg<\/code> est critique pour la s\u00e9curit\u00e9 : c’est pr\u00e9cis\u00e9ment ce champ que les attaquants tentent de manipuler avec l’attaque alg: none<\/code>, dont nous parlerons plus loin.<\/p>\n\n\n\n
{\n  \"alg\": \"HS256\",\n  \"typ\": \"JWT\"\n}<\/code><\/pre>\n\n\n\n
Le payload : les revendications (claims)<\/h3>\n\n\n\n
Le deuxi\u00e8me segment contient les claims. On distingue les claims enregistr\u00e9s, standardis\u00e9s par la RFC 7519, et les claims priv\u00e9s que vous d\u00e9finissez. Les claims enregistr\u00e9s les plus utiles sont exp<\/code> (expiration), iat<\/code> (date d’\u00e9mission), sub<\/code> (sujet), iss<\/code> (\u00e9metteur) et aud<\/code> (audience). Point crucial : la biblioth\u00e8que jsonwebtoken<\/code> n’applique aucune valeur par d\u00e9faut<\/strong> pour expiresIn<\/code>, audience<\/code>, issuer<\/code> ou subject<\/code>. Si vous ne les d\u00e9finissez pas, vos jetons n’expirent jamais.<\/p>\n\n\n\n
{\n  \"sub\": \"123\",\n  \"role\": \"admin\",\n  \"iat\": 1780496400,\n  \"exp\": 1780500000\n}<\/code><\/pre>\n\n\n\n
La signature : le verrou cryptographique<\/h3>\n\n\n\n
Le troisi\u00e8me segment est calcul\u00e9 en signant header.payload<\/code> avec une cl\u00e9 secr\u00e8te (HS256) ou une cl\u00e9 priv\u00e9e (RS256, ES256). Le serveur recalcule cette signature \u00e0 chaque requ\u00eate pour v\u00e9rifier que le jeton n’a pas \u00e9t\u00e9 modifi\u00e9. Changez un seul caract\u00e8re du payload et la signature ne correspond plus : la v\u00e9rification \u00e9choue. C’est exactement le principe des signatures num\u00e9riques<\/a> appliqu\u00e9 \u00e0 un format compact destin\u00e9 au web.<\/p>\n\n\n\n
HS256 vs RS256 vs ES256 : choisir le bon algorithme<\/h2>\n\n\n\n
Le choix de l’algorithme conditionne l’architecture enti\u00e8re. HS256 est sym\u00e9trique : la m\u00eame cl\u00e9 signe et v\u00e9rifie. RS256 et ES256 sont asym\u00e9triques : une cl\u00e9 priv\u00e9e signe, une cl\u00e9 publique v\u00e9rifie. Ce d\u00e9tail change tout d\u00e8s que plusieurs services doivent valider le m\u00eame jeton.<\/p>\n\n\n\n
Crit\u00e8re<\/th>HS256<\/th>RS256<\/th>ES256<\/th><\/tr><\/thead>
Type<\/td>Sym\u00e9trique (HMAC-SHA256)<\/td>Asym\u00e9trique (RSA)<\/td>Asym\u00e9trique (ECDSA P-256)<\/td><\/tr>
Cl\u00e9 de signature<\/td>Secret partag\u00e9<\/td>Cl\u00e9 priv\u00e9e RSA<\/td>Cl\u00e9 priv\u00e9e elliptique<\/td><\/tr>
Cl\u00e9 de v\u00e9rification<\/td>M\u00eame secret<\/td>Cl\u00e9 publique RSA<\/td>Cl\u00e9 publique elliptique<\/td><\/tr>
Taille de signature<\/td>Petite<\/td>Grande (256 octets pour RSA-2048)<\/td>Compacte (64 octets)<\/td><\/tr>
Cas d’usage id\u00e9al<\/td>Service unique, monolithe<\/td>Microservices, OIDC<\/td>Mobile, IoT, performances<\/td><\/tr>
Co\u00fbt de v\u00e9rification<\/td>Tr\u00e8s faible<\/td>\u00c9lev\u00e9<\/td>Mod\u00e9r\u00e9<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
R\u00e8gle pratique : si une seule application signe et v\u00e9rifie ses propres jetons, HS256 suffit<\/strong> et reste le plus simple. D\u00e8s que plusieurs services ind\u00e9pendants doivent v\u00e9rifier les jetons sans partager de secret, passez \u00e0 RS256 ou ES256. La cl\u00e9 publique se distribue librement, la cl\u00e9 priv\u00e9e reste sur le service d’authentification. ES256 produit des signatures plus compactes et des v\u00e9rifications plus rapides que RSA, ce qui en fait un excellent choix pour les contextes contraints. Pour approfondir la cryptographie \u00e0 courbes elliptiques, consultez notre guide sur les signatures num\u00e9riques ECDSA et EdDSA<\/a>.<\/p>\n\n\n\n
\u00c9tape 1 : initialiser le projet Node.js<\/h2>\n\n\n\n
Cr\u00e9ez un dossier de projet et initialisez-le avec npm. Nous utilisons les modules ES (type module<\/code>) pour b\u00e9n\u00e9ficier de la syntaxe import<\/code> moderne, d\u00e9sormais standard en 2026.<\/p>\n\n\n\n
mkdir jwt-auth-api && cd jwt-auth-api\nnpm init -y\nnpm pkg set type=\"module\"<\/code><\/pre>\n\n\n\n
Installez ensuite les d\u00e9pendances. Nous \u00e9pinglons jsonwebtoken<\/code> \u00e0 la version 9.0.3, valid\u00e9e sans vuln\u00e9rabilit\u00e9 connue, et ajoutons Express, bcrypt, dotenv et cookie-parser.<\/p>\n\n\n\n
npm install express jsonwebtoken@9.0.3 bcrypt dotenv cookie-parser\n# V\u00e9rifiez l'installation\nnpm list jsonwebtoken\n# jwt-auth-api@1.0.0\n# \u2514\u2500\u2500 jsonwebtoken@9.0.3<\/code><\/pre>\n\n\n\n
\u00c9tape 2 : g\u00e9n\u00e9rer et stocker un secret robuste<\/h2>\n\n\n\n
La s\u00e9curit\u00e9 de HS256 d\u00e9pend enti\u00e8rement de la force du secret. Un secret faible comme \"secret\"<\/code> ou \"123456\"<\/code> se casse par force brute en quelques secondes avec des outils comme hashcat. G\u00e9n\u00e9rez un secret al\u00e9atoire d’au moins 256 bits avec le module crypto<\/code> int\u00e9gr\u00e9.<\/p>\n\n\n\n
node -e \"console.log(require('crypto').randomBytes(48).toString('hex'))\"\n# Exemple de sortie :\n# 9f2c8a1e4b7d3f6a0c5e8b2d1f4a7c9e3b6d0f8a2c5e7b1d4f9a3c6e8b0d2f5a7c1e4b6d8<\/code><\/pre>\n\n\n\n
Copiez cette valeur dans un fichier .env<\/code> que vous ajoutez imm\u00e9diatement \u00e0 .gitignore<\/code>. Ne committez jamais un secret dans Git : c’est l’une des fuites les plus fr\u00e9quentes signal\u00e9es dans les analyses de fuites de donn\u00e9es<\/a>. Pr\u00e9voyez deux secrets distincts, un pour les access tokens et un pour les refresh tokens.<\/p>\n\n\n\n
# Fichier .env\nACCESS_TOKEN_SECRET=9f2c8a1e4b7d3f6a0c5e8b2d1f4a7c9e3b6d0f8a2c5e7b1d4f9a3c6e8b0d2f5a\nREFRESH_TOKEN_SECRET=a1b2c3d4e5f60718293a4b5c6d7e8f90123456789abcdef0fedcba9876543210\nPORT=3000<\/code><\/pre>\n\n\n\n
\u00c9tape 3 : hacher les mots de passe avec bcrypt<\/h2>\n\n\n\n
JWT g\u00e8re la session, pas les mots de passe. Avant d’\u00e9mettre le moindre jeton, hachez le mot de passe de l’utilisateur. N’utilisez jamais SHA-256 seul ni un stockage en clair : seuls des algorithmes lents et r\u00e9sistants au mat\u00e9riel d\u00e9di\u00e9 conviennent. bcrypt reste un choix solide, avec un facteur de co\u00fbt (rounds) configurable. Pour une s\u00e9curit\u00e9 de pointe, argon2id est encore meilleur, comme d\u00e9taill\u00e9 dans notre guide d\u00e9di\u00e9 au hachage Argon2 en Node.js<\/a>.<\/p>\n\n\n\n
\/\/ auth\/password.js\nimport bcrypt from 'bcrypt';\n\nconst SALT_ROUNDS = 12;\n\nexport async function hashPassword(plain) {\n  return bcrypt.hash(plain, SALT_ROUNDS);\n}\n\nexport async function verifyPassword(plain, hash) {\n  return bcrypt.compare(plain, hash);\n}<\/code><\/pre>\n\n\n\n
Un facteur de co\u00fbt de 12 offre un bon \u00e9quilibre en 2026 : assez lent pour d\u00e9courager les attaques par force brute, assez rapide pour ne pas bloquer le serveur sur chaque connexion. Mesurez le temps de hachage sur votre mat\u00e9riel et visez environ 250 ms par op\u00e9ration. Si vos serveurs sont plus puissants, augmentez \u00e0 13 ou 14.<\/p>\n\n\n\n
\u00c9tape 4 : cr\u00e9er la fonction de g\u00e9n\u00e9ration d’access token<\/h2>\n\n\n\n
Place au c\u0153ur du sujet. La fonction signAccessToken<\/code> encapsule l’appel \u00e0 jwt.sign<\/code>. Notez les options explicites : expiresIn<\/code> court (15 minutes), issuer<\/code> et audience<\/code> d\u00e9finis. Ces deux derniers claims permettront de rejeter un jeton \u00e9mis par un autre service.<\/p>\n\n\n\n
\/\/ auth\/tokens.js\nimport jwt from 'jsonwebtoken';\nimport 'dotenv\/config';\n\nconst ACCESS_SECRET = process.env.ACCESS_TOKEN_SECRET;\nconst REFRESH_SECRET = process.env.REFRESH_TOKEN_SECRET;\n\nexport function signAccessToken(user) {\n  return jwt.sign(\n    { role: user.role },\n    ACCESS_SECRET,\n    {\n      subject: String(user.id),\n      expiresIn: '15m',\n      issuer: 'jwt-auth-api',\n      audience: 'jwt-auth-client',\n      algorithm: 'HS256',\n    }\n  );\n}<\/code><\/pre>\n\n\n\n
\u00c9vitez d’entasser des donn\u00e9es dans le payload. Plus le jeton est gros, plus il alourdit chaque requ\u00eate HTTP. Mettez l’identifiant dans sub<\/code>, le r\u00f4le si n\u00e9cessaire, et rien d’autre. Toute donn\u00e9e modifiable (nom, e-mail) doit \u00eatre recharg\u00e9e depuis la base \u00e0 partir de l’identifiant, sinon elle devient obsol\u00e8te d\u00e8s que l’utilisateur la change.<\/p>\n\n\n\n
\u00c9tape 5 : g\u00e9n\u00e9rer un refresh token s\u00e9par\u00e9<\/h2>\n\n\n\n
L’access token est volontairement \u00e9ph\u00e9m\u00e8re pour limiter les d\u00e9g\u00e2ts en cas de vol. Le refresh token, \u00e0 dur\u00e9e plus longue, permet d’obtenir un nouvel access token sans redemander le mot de passe. Il utilise un secret diff\u00e9rent et une dur\u00e9e de vie plus longue, par exemple 7 jours. La documentation de jsonwebtoken<\/code> avertit que le rafra\u00eechissement automatique mal con\u00e7u introduit des failles : impl\u00e9mentez-le avec soin.<\/p>\n\n\n\n
export function signRefreshToken(user, tokenId) {\n  return jwt.sign(\n    { tokenId },\n    REFRESH_SECRET,\n    {\n      subject: String(user.id),\n      expiresIn: '7d',\n      issuer: 'jwt-auth-api',\n      audience: 'jwt-auth-client',\n      algorithm: 'HS256',\n    }\n  );\n}<\/code><\/pre>\n\n\n\n
Le champ tokenId<\/code> est la cl\u00e9 de la r\u00e9vocation. Stockez cet identifiant c\u00f4t\u00e9 serveur (base de donn\u00e9es ou Redis). Lors d’un rafra\u00eechissement, v\u00e9rifiez que le tokenId<\/code> existe toujours et n’a pas \u00e9t\u00e9 invalid\u00e9. Cette approche r\u00e9introduit juste assez d’\u00e9tat pour permettre une d\u00e9connexion r\u00e9elle, sans sacrifier la scalabilit\u00e9 de l’access token.<\/p>\n\n\n\n
Type de jeton<\/th>Dur\u00e9e recommand\u00e9e<\/th>Stockage c\u00f4t\u00e9 client<\/th>Secret utilis\u00e9<\/th><\/tr><\/thead>
Access token<\/td>5 \u00e0 15 minutes<\/td>M\u00e9moire JavaScript<\/td>ACCESS_TOKEN_SECRET<\/td><\/tr>
Refresh token<\/td>7 \u00e0 30 jours<\/td>Cookie httpOnly + Secure<\/td>REFRESH_TOKEN_SECRET<\/td><\/tr>
Jeton de r\u00e9initialisation<\/td>15 \u00e0 60 minutes<\/td>Jamais persist\u00e9 c\u00f4t\u00e9 client<\/td>Secret d\u00e9di\u00e9<\/td><\/tr>
Jeton de v\u00e9rification e-mail<\/td>24 heures<\/td>Lien \u00e0 usage unique<\/td>Secret d\u00e9di\u00e9<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\u00c9tape 6 : construire le serveur Express et la route de connexion<\/h2>\n\n\n\n
Assemblons maintenant le serveur. Pour ce tutoriel, nous simulons une base de donn\u00e9es avec un tableau en m\u00e9moire. En production, remplacez-le par PostgreSQL, MongoDB ou tout autre stockage. La route \/login<\/code> v\u00e9rifie le mot de passe hach\u00e9, puis \u00e9met les deux jetons.<\/p>\n\n\n\n
\/\/ server.js\nimport express from 'express';\nimport cookieParser from 'cookie-parser';\nimport crypto from 'crypto';\nimport 'dotenv\/config';\nimport { hashPassword, verifyPassword } from '.\/auth\/password.js';\nimport { signAccessToken, signRefreshToken } from '.\/auth\/tokens.js';\n\nconst app = express();\napp.use(express.json());\napp.use(cookieParser());\n\n\/\/ Base de donnees simulee\nconst users = [];\nconst validRefreshTokens = new Set();\n\n\/\/ Inscription\napp.post('\/register', async (req, res) => {\n  const { email, password } = req.body;\n  if (!email || !password) {\n    return res.status(400).json({ error: 'Champs manquants' });\n  }\n  if (users.find(u => u.email === email)) {\n    return res.status(409).json({ error: 'Utilisateur existant' });\n  }\n  const hash = await hashPassword(password);\n  const user = { id: users.length + 1, email, passwordHash: hash, role: 'user' };\n  users.push(user);\n  res.status(201).json({ id: user.id, email: user.email });\n});<\/code><\/pre>\n\n\n\n
La route de connexion suit la m\u00eame logique mais \u00e9met les jetons. Le refresh token part dans un cookie httpOnly<\/code>, inaccessible au JavaScript du navigateur, ce qui le prot\u00e8ge du vol par XSS. L’access token est renvoy\u00e9 dans le corps de la r\u00e9ponse, \u00e0 conserver en m\u00e9moire c\u00f4t\u00e9 client.<\/p>\n\n\n\n
\/\/ Connexion\napp.post('\/login', async (req, res) => {\n  const { email, password } = req.body;\n  const user = users.find(u => u.email === email);\n  if (!user) {\n    return res.status(401).json({ error: 'Identifiants invalides' });\n  }\n  const ok = await verifyPassword(password, user.passwordHash);\n  if (!ok) {\n    return res.status(401).json({ error: 'Identifiants invalides' });\n  }\n\n  const tokenId = crypto.randomUUID();\n  validRefreshTokens.add(tokenId);\n\n  const accessToken = signAccessToken(user);\n  const refreshToken = signRefreshToken(user, tokenId);\n\n  res.cookie('refreshToken', refreshToken, {\n    httpOnly: true,\n    secure: true,\n    sameSite: 'strict',\n    maxAge: 7 * 24 * 60 * 60 * 1000,\n  });\n\n  res.json({ accessToken });\n});<\/code><\/pre>\n\n\n\n
\u00c9tape 7 : \u00e9crire le middleware de v\u00e9rification<\/h2>\n\n\n\n
Le middleware prot\u00e8ge les routes priv\u00e9es. Il extrait le jeton de l’en-t\u00eate Authorization: Bearer<\/code>, le v\u00e9rifie, et attache l’utilisateur d\u00e9cod\u00e9 \u00e0 la requ\u00eate. Point capital de s\u00e9curit\u00e9 : passez explicitement l’option algorithms: ['HS256']<\/code>. Sans cette liste blanche, un attaquant peut tenter de basculer l’algorithme et contourner la v\u00e9rification.<\/p>\n\n\n\n
\/\/ auth\/middleware.js\nimport jwt from 'jsonwebtoken';\nimport 'dotenv\/config';\n\nexport function authenticate(req, res, next) {\n  const header = req.headers['authorization'];\n  if (!header || !header.startsWith('Bearer ')) {\n    return res.status(401).json({ error: 'Jeton absent' });\n  }\n  const token = header.split(' ')[1];\n\n  try {\n    const payload = jwt.verify(token, process.env.ACCESS_TOKEN_SECRET, {\n      algorithms: ['HS256'],\n      issuer: 'jwt-auth-api',\n      audience: 'jwt-auth-client',\n    });\n    req.user = { id: payload.sub, role: payload.role };\n    next();\n  } catch (err) {\n    if (err.name === 'TokenExpiredError') {\n      return res.status(401).json({ error: 'Jeton expire' });\n    }\n    return res.status(403).json({ error: 'Jeton invalide' });\n  }\n}<\/code><\/pre>\n\n\n\n
Distinguez bien les codes d’erreur. Un TokenExpiredError<\/code> renvoie 401 pour signaler au client qu’il doit rafra\u00eechir son jeton. Une signature invalide renvoie 403 : le jeton est falsifi\u00e9, il n’y a rien \u00e0 rafra\u00eechir. Cette distinction permet au client de r\u00e9agir intelligemment plut\u00f4t que de d\u00e9connecter l’utilisateur au moindre incident.<\/p>\n\n\n\n
\u00c9tape 8 : prot\u00e9ger une route et tester le flux<\/h2>\n\n\n\n
Ajoutez une route prot\u00e9g\u00e9e qui renvoie le profil de l’utilisateur connect\u00e9. Le middleware authenticate<\/code> s’ex\u00e9cute avant le gestionnaire.<\/p>\n\n\n\n
import { authenticate } from '.\/auth\/middleware.js';\n\napp.get('\/me', authenticate, (req, res) => {\n  const user = users.find(u => u.id === Number(req.user.id));\n  if (!user) return res.status(404).json({ error: 'Introuvable' });\n  res.json({ id: user.id, email: user.email, role: user.role });\n});\n\nconst PORT = process.env.PORT || 3000;\napp.listen(PORT, () => console.log(`API sur le port ${PORT}`));<\/code><\/pre>\n\n\n\n
Testez le flux complet avec curl. Inscrivez un utilisateur, connectez-vous, r\u00e9cup\u00e9rez l’access token, puis appelez la route prot\u00e9g\u00e9e.<\/p>\n\n\n\n
# 1. Inscription\ncurl -X POST http:\/\/localhost:3000\/register \\\n  -H \"Content-Type: application\/json\" \\\n  -d '{\"email\":\"alice@example.com\",\"password\":\"MotDePasseFort!2026\"}'\n\n# 2. Connexion (recupere l'access token)\ncurl -X POST http:\/\/localhost:3000\/login \\\n  -H \"Content-Type: application\/json\" \\\n  -d '{\"email\":\"alice@example.com\",\"password\":\"MotDePasseFort!2026\"}'\n# Sortie : {\"accessToken\":\"eyJhbGciOiJIUzI1NiI...\"}\n\n# 3. Route protegee\ncurl http:\/\/localhost:3000\/me \\\n  -H \"Authorization: Bearer eyJhbGciOiJIUzI1NiI...\"\n# Sortie : {\"id\":1,\"email\":\"alice@example.com\",\"role\":\"user\"}<\/code><\/pre>\n\n\n\n
\u00c9tape 9 : impl\u00e9menter la rotation des refresh tokens<\/h2>\n\n\n\n
La rotation est la meilleure d\u00e9fense contre le vol de refresh token. \u00c0 chaque rafra\u00eechissement, on invalide l’ancien tokenId<\/code> et on en \u00e9met un nouveau. Si un jeton vol\u00e9 est r\u00e9utilis\u00e9 apr\u00e8s rotation, le serveur d\u00e9tecte la r\u00e9utilisation et r\u00e9voque toute la cha\u00eene, for\u00e7ant une reconnexion. Pour la th\u00e9orie, consultez l’analyse d’Auth0 sur les refresh tokens<\/a>.<\/p>\n\n\n\n
app.post('\/refresh', (req, res) => {\n  const token = req.cookies.refreshToken;\n  if (!token) return res.status(401).json({ error: 'Pas de refresh token' });\n\n  try {\n    const payload = jwt.verify(token, process.env.REFRESH_TOKEN_SECRET, {\n      algorithms: ['HS256'],\n      issuer: 'jwt-auth-api',\n      audience: 'jwt-auth-client',\n    });\n\n    \/\/ Detection de reutilisation\n    if (!validRefreshTokens.has(payload.tokenId)) {\n      return res.status(403).json({ error: 'Refresh token revoque' });\n    }\n\n    \/\/ Rotation : on invalide l'ancien, on emet un nouveau\n    validRefreshTokens.delete(payload.tokenId);\n    const newTokenId = crypto.randomUUID();\n    validRefreshTokens.add(newTokenId);\n\n    const user = users.find(u => u.id === Number(payload.sub));\n    const accessToken = signAccessToken(user);\n    const refreshToken = signRefreshToken(user, newTokenId);\n\n    res.cookie('refreshToken', refreshToken, {\n      httpOnly: true, secure: true, sameSite: 'strict',\n      maxAge: 7 * 24 * 60 * 60 * 1000,\n    });\n    res.json({ accessToken });\n  } catch (err) {\n    return res.status(403).json({ error: 'Refresh token invalide' });\n  }\n});<\/code><\/pre>\n\n\n\n
\u00c9tape 10 : g\u00e9rer la d\u00e9connexion et la r\u00e9vocation<\/h2>\n\n\n\n
Comme les JWT sont sans \u00e9tat, un access token reste valide jusqu’\u00e0 son expiration m\u00eame apr\u00e8s d\u00e9connexion. C’est pourquoi on garde l’access token court (15 minutes maximum). La d\u00e9connexion consiste \u00e0 supprimer le refresh token c\u00f4t\u00e9 serveur et \u00e0 effacer le cookie c\u00f4t\u00e9 client. L’access token restant expirera de lui-m\u00eame en quelques minutes.<\/p>\n\n\n\n
app.post('\/logout', (req, res) => {\n  const token = req.cookies.refreshToken;\n  if (token) {\n    try {\n      const payload = jwt.verify(token, process.env.REFRESH_TOKEN_SECRET, {\n        algorithms: ['HS256'],\n      });\n      validRefreshTokens.delete(payload.tokenId);\n    } catch (_) { \/* jeton deja invalide, on ignore *\/ }\n  }\n  res.clearCookie('refreshToken');\n  res.json({ message: 'Deconnexion reussie' });\n});<\/code><\/pre>\n\n\n\n
Pour une r\u00e9vocation imm\u00e9diate des access tokens (cas d’un compte compromis), maintenez une liste de r\u00e9vocation (denylist) en Redis, index\u00e9e par sub<\/code> ou par identifiant de jeton, avec une expiration automatique cal\u00e9e sur la dur\u00e9e de l’access token. Le middleware consulte cette liste \u00e0 chaque requ\u00eate. C’est un compromis : on perd un peu de l’avantage sans \u00e9tat, mais on gagne une r\u00e9vocation instantan\u00e9e.<\/p>\n\n\n\n