Next.js Edge et middleware : authentifier proprement face à un Drupal

Dans une architecture Drupal découplé, Next.js absorbe toute la couche de présentation. La tentation est grande de traiter l'authentification comme un problème de front-end : on lit un cookie, on vérifie un token, on laisse passer ou on redirige. Avec le runtime Edge et les middleware Next.js, c'est exactement ce qu'on fait — sauf que le contexte d'exécution brise les patterns classiques.

Le runtime Edge n'est pas Node.js. Il tourne sur des nœuds CDN géographiquement distribués, sans accès à une base de données, sans la bibliothèque crypto complète de Node, et avec une API limitée à ce qu'expose le Web standard. Drupal, lui, reste dans un datacenter central. La session Drupal classique, stockée en base, ne peut pas être validée à l'edge sans un appel réseau, et un appel réseau depuis l'edge vers votre datacenter annule l'essentiel du bénéfice.

Ce que le runtime Edge change pour l'authentification

Le fichier middleware.ts de Next.js s'exécute à l'edge, avant que la requête atteigne le serveur régional. C'est le bon endroit pour protéger des routes, injecter des headers, et rediriger les utilisateurs non authentifiés. C'est aussi le mauvais endroit pour faire ce qu'on fait d'habitude.

Valider une session Drupal est impossible à l'edge. Drupal stocke ses sessions en base (table sessions) ou en cache Redis. Pour savoir si un identifiant de session est valide, il faut interroger ce stockage. L'edge n'y a pas accès directement, et un appel HTTP vers votre backend Drupal à chaque requête crée une latence qui efface le gain géographique.

Ce que l'edge peut faire : lire des cookies httpOnly, vérifier la signature d'un JWT avec Web Crypto, inspecter des claims (expiration, audience, issuer), réécrire ou rediriger la requête. C'est le contrat à partir duquel construire.

Trois options pour authentifier à l'edge

Cookies httpOnly chiffrés avec JWT court

C'est l'option la plus robuste pour les architectures où Next.js pilote l'expérience utilisateur. Après une connexion réussie sur le serveur régional (échange OAuth2 avec Drupal via le module Simple OAuth), un JWT signé est stocké dans un cookie httpOnly; Secure; SameSite=Strict. Le middleware Edge lit ce cookie à chaque requête et vérifie la signature avec Web Crypto. Si le token est valide et non expiré, la requête passe. Si le token est expiré, le middleware redirige vers une route de rafraîchissement sur le serveur régional.

Le cookie httpOnly interdit son accès depuis JavaScript côté client : une fuite XSS n'expose pas directement le token. Le TTL court (15 à 30 minutes) réduit la fenêtre d'exploitation en cas de compromission.

Tokens courts avec endpoint JWKS

Pour les architectures où Drupal émet directement les tokens OAuth2, exposer un endpoint JWKS (/.well-known/jwks.json) sur Drupal permet à l'Edge de valider les tokens sans roundtrip vers Drupal. L'avantage : les tokens peuvent être consommés par plusieurs services sans configuration spécifique par client. L'inconvénient : une rotation de clé Drupal impose un redéploiement Next.js pour recharger le JWKS.

Échanges signés HMAC pour les appels serveur-à-serveur

Cette option concerne les appels que les API routes de Next.js font vers Drupal (récupération de contenu protégé, mise à jour de données). Chaque requête est signée avec un secret partagé (HMAC-SHA256), en incluant un timestamp pour éviter les attaques par rejeu. À réserver aux échanges machine-à-machine.

Ce qui reste côté serveur régional

Le rafraîchissement de token nécessite un appel HTTP vers Drupal. Il se fait dans une API route Next.js, pas dans le middleware. L'échange OAuth2 initial implique des secrets côté serveur qui ne doivent pas être exposés dans l'environnement Edge. La révocation de token : si un utilisateur se déconnecte avant l'expiration du token, l'edge continuera à laisser passer les requêtes jusqu'à ce TTL. Deux options : garder un TTL très court (15 min) et accepter cette fenêtre, ou maintenir une liste noire de tokens révoqués sur le serveur régional.

Le flux recommandé

Le middleware lit le cookie token et valide la signature JWT via Web Crypto. Si le token est valide, la requête passe. Si le token est expiré, le middleware réécrit la requête vers /api/auth/refresh sur le serveur régional. Le serveur appelle l'endpoint de refresh de Drupal, pose un nouveau cookie httpOnly, puis redirige vers la destination originale. Si aucun token n'est présent, redirection vers la connexion.

Le middleware ne fait que lire et valider. Tout ce qui modifie un état se passe sur le serveur régional.

Les en-têtes à poser

Sur le cookie d'authentification :

Set-Cookie: token=<jwt>; HttpOnly; Secure; SameSite=Strict; Path=/; Max-Age=900

Sur toutes les réponses authentifiées :

Cache-Control: private, no-store Vary: Cookie

Un cache CDN qui stocke une réponse authentifiée et la sert à un autre utilisateur est une fuite de données. Cache-Control: private, no-store prévient ce scénario. Sur l'ensemble du site, via le middleware :

X-Frame-Options: DENY Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Plan de tests

• Expiration. Générer un JWT avec un exp dans le passé. Le middleware doit rediriger vers le refresh, pas laisser passer.
• Signature invalide. Modifier un caractère dans le payload du JWT sans le signer à nouveau. Le middleware doit rejeter et rediriger vers la connexion.
• Cookie accessible en JS. Vérifier que le token n'apparaît pas dans document.cookie depuis la console. Si c'est le cas, le flag httpOnly n'est pas posé.
• Fuite sur réponse publique. Vérifier qu'une réponse d'une route publique ne porte pas Set-Cookie avec des tokens utilisateur.
• Logout. Après déconnexion, une requête vers une route protégée doit rediriger vers la connexion.
• Rotation de clé. Après changement de la clé de signature, les tokens signés avec l'ancienne clé doivent être rejetés immédiatement.

Ce que cela donne en pratique

Une architecture Next.js Edge avec Drupal découplé peut être rapide et sûre si l'authentification respecte la séparation des responsabilités : l'edge valide, le serveur régional gère les états et les échanges avec Drupal. Les quatre décisions à fixer avant de commencer : format du token (JWT RS256 recommandé), TTL du token, stratégie de révocation, et où est stocké le refresh token.

Chez DrupaLabs, ce genre d'architecture fait partie des diagnostics que nous menons avant de construire ou de reprendre un projet découplé.