Maîtriser le Développement Backend avec Node.js et Express.js : Construisez vos API REST
Maîtriser le Développement Backend avec Node.js et Express.js : Construisez vos API REST

Sécuriser les API REST : Authentification et Autorisation avec JWT

Dans le monde du développement backend moderne, la création d'API REST robustes et sécurisées est une compétence fondamentale. Nos API servent de passerelles vers nos données et nos services, et sans une sécurité adéquate, elles sont des cibles faciles pour les attaques malveillantes. Ce cours, "Maîtriser le Développement Backend avec Node.js et Express.js : Construisez vos API REST", aborde une pierre angulaire de cette sécurité : l'authentification et l'autorisation, spécifiquement en utilisant les JSON Web Tokens (JWT).

Cette leçon vous guidera à travers les concepts essentiels et l'implémentation pratique des JWT pour protéger vos API Node.js et Express.js. Nous commencerons par les bases de l'authentification et de l'autorisation, explorerons la structure et le fonctionnement des JWT, puis plongerons dans des exemples de code concrets pour mettre en œuvre ces mécanismes dans votre application.

1. Les Fondamentaux de la Sécurité des API REST

Avant de plonger dans les JWT, il est crucial de comprendre les concepts de base qui sous-tendent la sécurité des API.

1.1 Authentification vs. Autorisation : Ne Confondez Pas !

Ces deux termes sont souvent utilisés de manière interchangeable, mais ils désignent des processus distincts et complémentaires :

  • Authentification (Qui êtes-vous ?) : C'est le processus de vérification de l'identité d'un utilisateur ou d'un client. Lorsque vous vous connectez à un site web avec un nom d'utilisateur et un mot de passe, vous êtes en train de vous authentifier. Le système vérifie si vous êtes bien celui que vous prétendez être.

    • Exemple : Présenter votre passeport à la douane pour prouver votre identité.

  • Autorisation (Que pouvez-vous faire ?) : C'est le processus de détermination des droits d'accès d'un utilisateur authentifié à des ressources ou des actions spécifiques. Une fois que votre identité est confirmée, l'autorisation détermine ce que vous êtes autorisé à voir, à modifier ou à exécuter.

    • Exemple : Une fois que votre identité est vérifiée à la douane, votre visa (ou l'absence de visa) détermine si vous êtes autorisé à entrer dans le pays, et où vous pouvez aller.

En bref : l'authentification établit l'identité ; l'autorisation définit les permissions.

1.2 Pourquoi les Méthodes Traditionnelles ne Suffisent Pas Toujours pour les API REST ?

Les API REST sont par nature stateless (sans état), ce qui signifie que chaque requête du client au serveur doit contenir toutes les informations nécessaires à la compréhension de la requête. Le serveur ne conserve pas de "mémoire" des requêtes précédentes.

  • Sessions Basées sur les Cookies :

    • Comment ça marche : Le serveur crée une session côté serveur, stocke un identifiant de session unique dans un cookie sur le client. Chaque requête inclut ce cookie, permettant au serveur de retrouver la session.
    • Inconvénients pour les API REST :
      • Stateful : Le serveur doit maintenir l'état de la session, ce qui peut poser des problèmes de scalabilité (où stocker les sessions dans une architecture distribuée ?) et de gestion (expiration, nettoyage).
      • CORS (Cross-Origin Resource Sharing) : Les cookies peuvent être problématiques dans un contexte d'API où le frontend et le backend sont sur des domaines différents.
      • CSRF (Cross-Site Request Forgery) : Les cookies sont vulnérables aux attaques CSRF si des précautions ne sont pas prises.

  • Clés d'API (API Keys) :

    • Comment ça marche : Une chaîne de caractères unique est générée et attribuée à un client (par exemple, une application mobile ou un service tiers). Cette clé est ensuite envoyée avec chaque requête.
    • Inconvénients :
      • Sécurité limitée : Souvent transmises en clair ou avec un chiffrement minimal, elles peuvent être facilement interceptées.
      • Gestion des clés : La révocation d'une clé compromise est difficile, et leur distribution sécurisée peut être un défi.
      • Manque de granularité : Difficile d'implémenter des permissions fines pour différents utilisateurs ou rôles.

Les JWT résolvent bon nombre de ces problèmes en offrant une solution stateless, sécurisée et flexible pour l'authentification et l'autorisation dans les API REST.

2. Introduction aux JSON Web Tokens (JWT)

Les JSON Web Tokens (prononcé "jot") sont devenus le standard de facto pour la sécurisation des API modernes.

2.1 Qu'est-ce qu'un JWT ?

Un JSON Web Token (JWT) est un moyen compact et auto-suffisant de transmettre des informations entre des parties sous forme d'un objet JSON. Ces informations peuvent être vérifiées et fiables car elles sont numériquement signées.

  • Compact : La petite taille permet de le transmettre rapidement via l'URL, un paramètre POST ou dans un en-tête HTTP.
  • Auto-suffisant (Self-Contained) : Le token contient toutes les informations nécessaires sur l'utilisateur, évitant au serveur d'avoir à interroger une base de données à chaque requête pour récupérer les informations de session. C'est l'essence de son aspect stateless.
  • Vérifiable et Fiable : La signature numérique du token garantit que les informations n'ont pas été altérées et qu'elles proviennent d'une source fiable.

2.2 Structure d'un JWT

Un JWT se compose de trois parties séparées par des points (.), généralement encodées en Base64Url :

Header.Payload.Signature

  1. Header (En-tête) :

    • Contient le type de token (JWT) et l'algorithme de signature utilisé (par exemple, HMAC SHA256 ou RSA).
    • Exemple : 
      {
  "alg": "HS256",
  "typ": "JWT"
}
    • Encodé en Base64Url : eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

  2. Payload (Charge utile) :

    • Contient les "claims" (revendications), qui sont des déclarations sur l'entité (généralement l'utilisateur) et des données supplémentaires. Il existe trois types de claims :
      • Registered Claims : Revendications prédéfinies et recommandées (non obligatoires) pour assurer l'interopérabilité. Exemples :
        • iss (issuer) : L'émetteur du token.
        • exp (expiration time) : Le temps d'expiration après lequel le token ne doit plus être accepté.
        • sub (subject) : Le sujet du token (généralement l'ID de l'utilisateur).
        • aud (audience) : Le destinataire pour qui le token est destiné.
        • iat (issued at) : L'heure à laquelle le JWT a été émis.
      • Public Claims : Définies par des utilisateurs JWT pour des cas d'utilisation spécifiques, mais enregistrées publiquement pour éviter les collisions.
      • Private Claims : Définies par les parties qui se mettent d'accord pour les utiliser (ex: userId, role, companyId). Ce sont les plus courantes pour transporter des données spécifiques à l'application.
    • Exemple : 
      {
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true,
  "iat": 1516239022,
  "exp": 1516242622
}
    • Encodé en Base64Url : eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsImlhdCI6MTUxNjIzOTAyMiwiZXhwIjoxNTE2MjQyNjIyfQ

  3. Signature :

    • Créée en prenant l'en-tête encodé, la charge utile encodée, une clé secrète, et l'algorithme spécifié dans l'en-tête.
    • Signature = HmacSHA256( Base64UrlEncode(Header) + "." + Base64UrlEncode(Payload), votre_secret_super_secure )
    • La signature permet au serveur de vérifier que le token n'a pas été altéré et qu'il a bien été émis par le serveur lui-même.

2.3 Comment ça marche ? Le Flux de l'Authentification JWT

Le processus d'authentification et d'autorisation avec JWT se déroule généralement comme suit :

  1. L'utilisateur s'authentifie : Le client (navigateur, application mobile) envoie les identifiants (username/password) au serveur via une requête de connexion (souvent POST /api/login).
  2. Le serveur vérifie les identifiants : Le serveur valide le nom d'utilisateur et le mot de passe (généralement en hachant le mot de passe reçu et en le comparant au hachage stocké en base de données).
  3. Le serveur génère un JWT : Si les identifiants sont corrects, le serveur crée un JWT. Ce token inclut des informations sur l'utilisateur (son ID, ses rôles, etc.) dans la charge utile (payload), et le signe avec une clé secrète qui n'est connue que du serveur.
  4. Le JWT est renvoyé au client : Le serveur envoie le JWT au client dans la réponse de la requête de connexion.
  5. Le client stocke le JWT : Le client stocke le JWT. Les options courantes sont le localStorage, sessionStorage ou un cookie (HttpOnly pour plus de sécurité).
  6. Le client envoie le JWT avec les requêtes ultérieures : Pour accéder aux ressources protégées, le client inclut le JWT dans l'en-tête Authorization de chaque requête subséquente, généralement sous la forme Authorization: Bearer <token>.
  7. Le serveur valide le JWT : À chaque requête contenant un JWT, le serveur :
    • Vérifie que le token est correctement formaté.
    • Vérifie la signature du token en utilisant la même clé secrète. Si la signature est invalide, cela signifie que le token a été altéré ou qu'il n'a pas été émis par ce serveur.
    • Vérifie l'expiration du token (exp claim).
    • Décode la charge utile (payload) pour extraire les informations de l'utilisateur.
  8. Le serveur autorise l'accès : Sur la base des informations contenues dans le payload (par exemple, les rôles de l'utilisateur), le serveur détermine si l'utilisateur est autorisé à accéder à la ressource demandée. Si oui, la requête est traitée ; sinon, une erreur (par exemple, 403 Forbidden) est renvoyée.

3. Implémentation de l'Authentification avec JWT (Node.js/Express.js)

Nous allons maintenant voir comment implémenter ce flux avec Node.js et Express.js.

3.1 Prérequis

Assurez-vous d'avoir les paquets nécessaires installés :

npm install express jsonwebtoken bcrypt dotenv
  • express : Pour créer notre serveur API.
  • jsonwebtoken : Pour générer et vérifier les JWT.
  • bcrypt : Pour hacher les mots de passe de manière sécurisée.
  • dotenv : Pour gérer les variables d'environnement (notamment notre clé secrète JWT).

Créez un fichier .env à la racine de votre projet pour stocker votre clé secrète JWT. IMPORTANT : Ne partagez jamais votre clé secrète !

JWT_SECRET=votre_secret_jwt_tres_long_et_complexe

Et chargez-le au début de votre application Express (app.js ou server.js) :

// server.js
require('dotenv').config(); // Charge les variables d'environnement du fichier .env
const express = require('express');
const app = express();
// ...

3.2 Flux d'Authentification : Enregistrement et Connexion

Nous allons simuler une base de données simple en mémoire pour cet exemple. Dans une application réelle, vous utiliseriez MongoDB, PostgreSQL, etc.

userModel.js (Simule une base de données utilisateur)

// userModel.js
const bcrypt = require('bcrypt');

const users = []; // Base de données en mémoire pour l'exemple

exports.findByUsername = (username) => {
    return users.find(user => user.username === username);
};

exports.createUser = async (username, password) => {
    const hashedPassword = await bcrypt.hash(password, 10); // Hacher le mot de passe
    const newUser = { id: users.length + 1, username, password: hashedPassword, role: 'user' };
    users.push(newUser);
    return newUser;
};

authController.js (Logique d'enregistrement et de connexion)

// authController.js
const jwt = require('jsonwebtoken');
const bcrypt = require('bcrypt');
const userModel = require('./userModel'); // Notre 'base de données' utilisateur

const JWT_SECRET = process.env.JWT_SECRET;

exports.register = async (req, res) => {
    try {
        const { username, password } = req.body;

        // Vérifier si l'utilisateur existe déjà
        if (userModel.findByUsername(username)) {
            return res.status(409).json({ message: 'Username already taken.' });
        }

        const newUser = await userModel.createUser(username, password);
        // Ne jamais renvoyer le mot de passe haché au client
        const { password: _, ...userWithoutPassword } = newUser;
        res.status(201).json({ message: 'User registered successfully', user: userWithoutPassword });

    } catch (error) {
        console.error('Registration error:', error);
        res.status(500).json({ message: 'Server error during registration.' });
    }
};

exports.login = async (req, res) => {
    try {
        const { username, password } = req.body;

        const user = userModel.findByUsername(username);
        if (!user) {
            return res.status(401).json({ message: 'Invalid credentials.' });
        }

        const isPasswordValid = await bcrypt.compare(password, user.password);
        if (!isPasswordValid) {
            return res.status(401).json({ message: 'Invalid credentials.' });
        }

        // --- Génération du JWT ---
        // Le payload contient des informations que nous voulons transporter avec le token.
        // Évitez d'y mettre des informations sensibles qui ne devraient pas être publiques.
        // L'ID utilisateur et le rôle sont de bonnes informations à inclure.
        const token = jwt.sign(
            { id: user.id, username: user.username, role: user.role },
            JWT_SECRET,
            { expiresIn: '1h' } // Le token expire après 1 heure
        );

        res.status(200).json({ message: 'Logged in successfully', token });

    } catch (error) {
        console.error('Login error:', error);
        res.status(500).json({ message: 'Server error during login.' });
    }
};

Explication du code de authController.js :

  • JWT_SECRET : C'est la clé secrète utilisée pour signer le token. Elle est cruciale pour la sécurité et doit être stockée en toute sécurité (via les variables d'environnement, comme montré avec dotenv).
  • register :
    • Hache le mot de passe fourni par l'utilisateur à l'aide de bcrypt.hash(). Le 10 est le saltRounds, plus il est élevé, plus le hachage est sûr, mais plus il est lent.
    • Stocke l'utilisateur avec le mot de passe haché.
  • login :
    • Récupère l'utilisateur par son nom d'utilisateur.
    • Compare le mot de passe fourni avec le mot de passe haché stocké en utilisant bcrypt.compare(). C'est une opération asynchrone.
    • Si les identifiants sont valides, jwt.sign() est appelé pour créer le JWT.
      • Le premier argument est le payload (charge utile), un objet JavaScript qui sera encodé dans le token. Nous y mettons l'id de l'utilisateur, son username et son role.
      • Le deuxième argument est la clé secrète (JWT_SECRET).
      • Le troisième argument est un objet d'options, où nous définissons expiresIn: '1h'. Cela signifie que le token sera valide pendant une heure. Après cela, le client devra se reconnecter ou utiliser un refresh token (voir section bonnes pratiques).
    • Le token généré est ensuite renvoyé au client.

3.2.2 Stockage et Transmission du JWT

Une fois que le client reçoit le JWT, il doit le stocker et le transmettre avec chaque requête protégée.

  • Stockage côté client :

    • localStorage / sessionStorage : Facile à utiliser en JavaScript côté client. Cependant, ces stockages sont vulnérables aux attaques XSS (Cross-Site Scripting) si votre application n'est pas sécurisée, car le JavaScript malveillant pourrait y accéder.
    • HttpOnly Cookies : Un cookie marqué HttpOnly ne peut pas être accédé par le JavaScript côté client, ce qui réduit considérablement le risque d'attaques XSS. C'est l'option la plus sécurisée pour stocker des JWT. Cependant, cela peut être plus complexe à gérer avec les API REST stateless car les cookies sont par nature liés au concept de session.
    • Pour les API REST pures, le stockage dans le localStorage est très courant, à condition que le frontend soit diligent sur la prévention des XSS (Content Security Policy, sanitisation des inputs, etc.).

  • Transmission du JWT : Le moyen standard et recommandé pour transmettre un JWT est via l'en-tête Authorization avec le schéma Bearer.

    Authorization: Bearer <votre_jwt_ici>

    Exemple de requête côté client (JavaScript avec fetch) :

    // Supposons que vous ayez stocké le token après la connexion
const token = localStorage.getItem('jwt_token');

fetch('/api/protected-resource', {
    method: 'GET',
    headers: {
        'Authorization': `Bearer ${token}`, // Inclut le JWT dans l'en-tête
        'Content-Type': 'application/json'
    }
})
.then(response => response.json())
.then(data => console.log(data))
.catch(error => console.error('Error:', error));

4. Implémentation de l'Autorisation avec JWT (Node.js/Express.js)

Maintenant que nous pouvons générer et transmettre des JWT, nous devons créer un middleware pour vérifier ces tokens et protéger nos routes.

4.1 Middleware de Vérification du JWT

Un middleware est une fonction qui a accès à l'objet requête (req), l'objet réponse (res) et la fonction next() dans le cycle requête-réponse d'Express. Il peut exécuter du code, modifier les objets requête et réponse, et terminer le cycle ou passer le contrôle au prochain middleware.

authMiddleware.js

// authMiddleware.js
const jwt = require('jsonwebtoken');

const JWT_SECRET = process.env.JWT_SECRET;

exports.authenticateToken = (req, res, next) => {
    // 1. Récupérer l'en-tête Authorization
    const authHeader = req.headers['authorization'];
    // L'en-tête est typiquement "Bearer TOKEN", donc on split pour obtenir seulement le TOKEN
    const token = authHeader && authHeader.split(' ')[1];

    // 2. Vérifier si un token existe
    if (token == null) {
        return res.status(401).json({ message: 'Access Denied: No token provided.' });
    }

    // 3. Vérifier le token
    jwt.verify(token, JWT_SECRET, (err, user) => {
        if (err) {
            // jwt.verify renvoie une erreur si le token est invalide (signature, expiration, etc.)
            return res.status(403).json({ message: 'Access Denied: Invalid or expired token.' });
        }
        // Si le token est valide, le payload décodé est 'user'
        // Nous attachons les informations de l'utilisateur à l'objet 'req'
        // pour qu'elles soient disponibles dans les route handlers suivants.
        req.user = user;
        next(); // Passe le contrôle au prochain middleware ou à la route handler
    });
};

Explication du code de authMiddleware.js :

  • Extraction du Token : Le token est extrait de l'en-tête Authorization. Il est formaté comme Bearer <token>, d'où l'utilisation de split(' ')[1].
  • Vérification de l'existence : Si aucun token n'est fourni, une erreur 401 (Unauthorized) est renvoyée.
  • Vérification du Token : jwt.verify() est la fonction clé.
    • Elle prend le token, la clé secrète, et une fonction de rappel.
    • Si le token est valide (signature correcte, non expiré), la fonction de rappel est appelée avec null pour err et le payload décodé dans user.
    • Si le token est invalide, err contiendra l'erreur (par exemple, TokenExpiredError, JsonWebTokenError pour signature invalide). Nous renvoyons alors une erreur 403 (Forbidden), car l'utilisateur a peut-être un token mais il n'est plus valide.
  • req.user = user; : C'est une pratique courante. Une fois le token vérifié, les informations de l'utilisateur (issues du payload) sont attachées à l'objet req. Cela permet aux fonctions de route suivantes d'accéder facilement à l'ID ou aux rôles de l'utilisateur sans avoir à redécoder le token.
  • next() : Si tout est bon, next() est appelé pour passer le contrôle à la prochaine fonction middleware dans la pile, ou à la fonction de route finale.

4.2 Protection des Routes

Maintenant, appliquons ce middleware à nos routes Express.

app.js (ou server.js)

// app.js (ou server.js)
require('dotenv').config();
const express = require('express');
const app = express();
const authController = require('./authController');
const authMiddleware = require('./authMiddleware');

const PORT = process.env.PORT || 3000;

app.use(express.json()); // Middleware pour parser les corps de requête JSON

// --- Routes d'authentification (publiques) ---
app.post('/api/register', authController.register);
app.post('/api/login', authController.login);

// --- Route protégée (nécessite un JWT valide) ---
// Le middleware authMiddleware.authenticateToken sera exécuté avant la fonction de route
app.get('/api/protected', authMiddleware.authenticateToken, (req, res) => {
    // Si nous arrivons ici, le token a été vérifié et req.user contient les informations
    res.status(200).json({
        message: 'Bienvenue sur la ressource protégée !',
        user: req.user // Affiche les infos de l'utilisateur issues du JWT
    });
});

// --- Route pour les administrateurs seulement (Autorisation basée sur les rôles) ---
// Nous aurons besoin d'un autre middleware pour vérifier le rôle.
// Pour le moment, passons à la section suivante pour le créer.

app.listen(PORT, () => {
    console.log(`Server running on port ${PORT}`);
});

Pour tester :

  1. Lancez le serveur.
  2. Envoyez une requête POST à /api/register avec un username et password.
  3. Envoyez une requête POST à /api/login avec les mêmes identifiants pour obtenir un JWT.
  4. Copiez le JWT reçu.
  5. Envoyez une requête GET à /api/protected :
    • Sans l'en-tête Authorization: vous devriez obtenir un 401.
    • Avec l'en-tête Authorization: Bearer <votre_jwt>: vous devriez obtenir la réponse de la route protégée.

4.3 Autorisation Basée sur les Rôles (RBAC) avec JWT

Pour une autorisation plus fine, nous pouvons utiliser les informations de rôle que nous avons incluses dans le payload du JWT.

roleMiddleware.js

// roleMiddleware.js

exports.authorizeRoles = (...allowedRoles) => {
    return (req, res, next) => {
        // req.user est défini par le middleware authenticateToken
        if (!req.user || !req.user.role) {
            return res.status(403).json({ message: 'Access Denied: No role found in token or user not authenticated.' });
        }

        // Vérifier si le rôle de l'utilisateur est parmi les rôles autorisés
        if (!allowedRoles.includes(req.user.role)) {
            return res.status(403).json({ message: 'Access Denied: Insufficient permissions.' });
        }

        next(); // L'utilisateur a le bon rôle, on peut passer
    };
};

Explication du code de roleMiddleware.js :

  • authorizeRoles est une factory function : elle prend en arguments les rôles autorisés (...allowedRoles) et retourne une fonction middleware. Cela permet de réutiliser ce middleware pour différentes routes nécessitant différents ensembles de rôles.
  • Elle s'appuie sur req.user qui est rempli par authenticateToken. Sans req.user, ce middleware ne fonctionnerait pas correctement.
  • Elle vérifie si le req.user.role est inclus dans la liste allowedRoles.

Mise à jour de app.js pour inclure le middleware de rôle :

// app.js (ou server.js)
// ... (imports existants)
const authMiddleware = require('./authMiddleware');
const roleMiddleware = require('./roleMiddleware'); // Nouveau import

// ... (routes /api/register et /api/login)

// --- Route protégée pour tous les utilisateurs authentifiés ---
app.get('/api/protected', authMiddleware.authenticateToken, (req, res) => {
    res.status(200).json({
        message: 'Bienvenue sur la ressource protégée !',
        user: req.user
    });
});

// --- Route accessible uniquement par les administrateurs ---
app.get('/api/admin',
    authMiddleware.authenticateToken, // D'abord, s'assurer que l'utilisateur est authentifié
    roleMiddleware.authorizeRoles('admin'), // Ensuite, vérifier si son rôle est 'admin'
    (req, res) => {
        res.status(200).json({
            message: 'Bienvenue sur le panneau d\'administration, ' + req.user.username + '!',
            user: req.user
        });
    }
);

// ... (app.listen)

Maintenant, si vous vous connectez en tant qu'utilisateur standard (role: 'user'), vous pourrez accéder à /api/protected mais obtiendrez un 403 pour /api/admin. Si vous modifiez manuellement le rôle de l'utilisateur enregistré en 'admin' dans votre userModel (pour les tests), vous pourrez accéder à /api/admin.

5. Sécurisation Avancée et Bonnes Pratiques

Les JWT sont puissants, mais leur mauvaise utilisation peut introduire de nouvelles vulnérabilités.

5.1 Gestion des Secrets

  • Jamais en clair : Votre JWT_SECRET doit être une chaîne de caractères longue, complexe et aléatoire. Ne la codez jamais en dur dans votre code source. Utilisez toujours des variables d'environnement (comme dotenv) ou des services de gestion de secrets (Vault, AWS Secrets Manager, Azure Key Vault).
  • Rotation des clés : Dans les environnements de production, envisagez de faire pivoter vos clés secrètes régulièrement pour minimiser l'impact d'une fuite potentielle.

5.2 Expiration des Tokens et Rafraîchissement (Refresh Tokens)

  • Tokens d'accès de courte durée : Les JWT (tokens d'accès) devraient avoir une courte durée de vie (quelques minutes à quelques heures). Cela réduit la fenêtre d'opportunité pour un attaquant qui intercepterait un token.
  • Problème : Si les tokens expirent rapidement, l'utilisateur doit se reconnecter souvent, ce qui dégrade l'expérience utilisateur.
  • Solution : Les Refresh Tokens :
    • Un refresh token est un token à longue durée de vie (jours, semaines) émis en plus du JWT lors de la connexion.
    • Il est stocké plus sécuritairement (par exemple, dans un cookie HttpOnly, ou une base de données sécurisée côté serveur).
    • Lorsque le JWT expire, le client envoie le refresh token à une API dédiée (/api/refresh-token).
    • Le serveur valide le refresh token (doit être unique, pas encore utilisé, non révoqué).
    • Si valide, le serveur émet un nouveau JWT (avec une nouvelle courte durée de vie) et potentiellement un nouveau refresh token.
    • Cela permet une expérience utilisateur fluide sans exposer un token d'accès de longue durée.

5.3 Révoquer un JWT (Blacklisting)

La nature stateless des JWT est une force, mais aussi une faiblesse pour la révocation immédiate : une fois qu'un JWT est signé et émis, il est valide jusqu'à son expiration. Si un utilisateur se déconnecte ou si un token est compromis, il reste valide.

  • Stratégies de révocation :
    • Expiration courte : La méthode la plus simple est d'avoir une courte durée de vie pour le JWT. Le token compromis ne sera valide que peu de temps.
    • Blacklisting : Maintenir une liste noire (en base de données ou dans un cache rapide comme Redis) des JWT révoqués (par leur ID unique jti si inclus dans le payload). À chaque vérification de token, le serveur vérifie d'abord si le token est sur cette liste noire. Cela introduit de l'état, mais est parfois nécessaire.
    • Changement de clé secrète : Si un secret est compromis, le changer immédiatement rendra tous les JWT précédemment signés invalides. Cependant, cela affecte tous les utilisateurs.

5.4 Vulnérabilités Courantes et Préventions

  • XSS (Cross-Site Scripting) : Si un attaquant injecte du JavaScript malveillant dans votre frontend, il pourrait lire le JWT depuis le localStorage ou sessionStorage.
    • Prévention : Implémentez des mesures de sécurité XSS strictes (Content Security Policy, échappement des inputs), et envisagez les cookies HttpOnly pour le stockage des tokens.
  • Attaques par Relecture (Replay Attacks) : Un attaquant intercepte un JWT valide et le réutilise.
    • Prévention : L'expiration courte des tokens aide beaucoup. L'utilisation d'un jti (JWT ID) unique et sa vérification côté serveur peut aussi prévenir la relecture.
  • Brute Force sur les Secrets : Si votre JWT_SECRET est faible, un attaquant pourrait le deviner.
    • Prévention : Utilisez des clés secrètes longues, complexes et aléatoires.
  • Algorithme "None" : Une ancienne vulnérabilité où le JWT pouvait être signé avec l'algorithme "none" (pas de signature), ce qui permettait à l'attaquant de créer son propre token.
    • Prévention : Les bibliothèques JWT modernes vérifient par défaut que l'algorithme spécifié dans l'en-tête correspond à l'algorithme attendu par le serveur et refusent les tokens signés avec "none" ou un algorithme inattendu.

Conclusion

La sécurisation de vos API REST est un aspect non négociable du développement backend. Les JSON Web Tokens (JWT) offrent une solution élégante et performante pour l'authentification et l'autorisation dans les architectures stateless de vos API Node.js et Express.js.

Nous avons exploré les différences fondamentales entre l'authentification et l'autorisation, compris la structure et le fonctionnement interne d'un JWT, et mis en œuvre des exemples pratiques de génération, de transmission et de vérification de ces tokens. De plus, nous avons abordé des stratégies essentielles pour l'autorisation basée sur les rôles et les bonnes pratiques de sécurité afin de prémunir vos applications contre les vulnérabilités courantes.

Maîtriser les JWT vous équipe d'un outil puissant pour construire des API sécurisées et résilientes. N'oubliez jamais que la sécurité est un processus continu. Continuez à vous informer sur les dernières menaces et les meilleures pratiques pour maintenir vos systèmes à l'abri des risques.