wp user application-password create formateur-api "Front Next.js" : une seule commande WP-CLI, et voilà un identifiant d’API généré sans avoir installé la moindre extension d’authentification. Sur une plateforme d’e-learning où chaque module doit être servi via l’API REST WordPress à un frontend Next.js, ce choix a évité tout un pan de configuration habituellement associé aux jetons JWT.
Les mots de passe d’application existent nativement dans WordPress depuis la version 5.6, sortie en décembre 2020. Contrairement à un plugin JWT qui ajoute une dépendance supplémentaire à maintenir et à surveiller côté sécurité, cette fonctionnalité fait partie du cœur, se configure depuis le profil utilisateur et se révoque tout aussi simplement. Voici comment la mettre en place pour authentifier un front Next.js consommant des routes protégées.
Étape 1 : générer un mot de passe d’application dédié
La première règle, souvent négligée, consiste à ne jamais réutiliser le mot de passe d’application d’un compte personnel pour un accès applicatif. Un utilisateur technique dédié, avec un rôle limité aux capacités strictement nécessaires, s’impose :
wp user create api-nextjs api@centre-formation.fr --role=editor
wp user application-password create api-nextjs "Front Next.js production"
La commande retourne un mot de passe généré une seule fois, affiché avec des espaces (par exemple abcd 1234 efgh 5678). Il doit être copié immédiatement dans le gestionnaire de secrets du projet : WordPress ne le réaffichera jamais en clair par la suite.
Étape 2 : stocker le secret côté serveur uniquement
Le mot de passe d’application ne doit jamais transiter vers le navigateur. Dans Next.js, cela signifie l’utiliser exclusivement dans une route API interne (pages/api/ ou un gestionnaire de route du dossier app/), jamais dans un composant côté client :
// app/api/modules/route.js
export async function GET() {
const auth = Buffer.from(
`${process.env.WP_API_USER}:${process.env.WP_API_PASSWORD}`
).toString('base64');
const res = await fetch('https://cms.centre-formation.fr/wp-json/wp/v2/module?status=publish', {
headers: { Authorization: `Basic ${auth}` },
});
return Response.json(await res.json());
}
Le front public appelle cette route interne, qui elle seule connaît les identifiants. Le navigateur ne voit jamais transiter le mot de passe d’application, ce qui limite drastiquement la surface d’exposition en cas de compromission du poste d’un apprenant.
Étape 3 : restreindre les capacités du compte technique
Un mot de passe d’application hérite des permissions du compte utilisateur associé. Créer un rôle personnalisé, plus restrictif qu’editor, réduit encore la casse en cas de fuite du secret :
- Retirer la capacité
publish_postssi le front ne fait que lire les contenus - Limiter l’accès aux types de contenus strictement nécessaires (modules, chapitres, quiz)
- Ne jamais attribuer le rôle
administratorà un compte applicatif
Sur ce projet, un rôle lecteur_api personnalisé, créé via add_role() et limité à la lecture des types de contenus pédagogiques, a remplacé le rôle éditeur par défaut trop permissif.
Étape 4 : gérer la rotation et la révocation
Chaque mot de passe d’application apparaît individuellement dans le profil de l’utilisateur, avec sa date de dernière utilisation. Cette visibilité facilite la rotation périodique : un nouveau mot de passe est généré, déployé dans les variables d’environnement de production, puis l’ancien est révoqué une fois le déploiement validé.
wp user application-password list api-nextjs
wp user application-password delete api-nextjs "Front Next.js production (ancien)"
Cette granularité par nom d’application, plutôt qu’un jeton unique difficile à distinguer d’un autre, a permis de retirer un accès précis lors du départ d’un prestataire sans toucher aux autres intégrations en place.
Étape 5 : surveiller les échecs d’authentification
Les tentatives d’authentification refusées via Basic Auth apparaissent dans les journaux du serveur avec un code 401. Un seuil d’alerte sur ces réponses permet de détecter rapidement un secret expiré côté déploiement, avant que les apprenants ne constatent une page blanche.
Notre verdict
Pour un front Next.js qui consomme une API REST WordPress avec un nombre limité de comptes techniques, les mots de passe d’application suffisent largement et évitent la complexité de gestion des jetons JWT (expiration, refresh, bibliothèque de vérification côté serveur). Le JWT reprend son intérêt dès qu’il faut authentifier des utilisateurs finaux individuels avec des sessions courtes, ce qui n’était pas le cas ici : seul le frontend lui-même avait besoin d’un accès applicatif stable à l’API.
