Depuis notre article sur les mots de passe d’application, une question revient régulièrement de la part de lecteurs qui découvrent le headless : pourquoi ne pas simplement utiliser JWT, la méthode la plus citée dans les tutoriels anglophones sur l’authentification WordPress headless ? La réponse mérite un comparatif détaillé, car les deux approches répondent à des besoins différents.
Aucune des deux méthodes n’est universellement supérieure à l’autre. Le bon choix dépend du contexte : type de client, durée de vie souhaitée des accès, et tolérance à la dépendance vis-à-vis d’un plugin tiers.
JWT : principe et mise en œuvre
JWT (JSON Web Token) n’est pas natif à WordPress. Il nécessite l’installation d’un plugin, le plus répandu étant « JWT Authentication for WP REST API ». Le principe : le client envoie un identifiant et un mot de passe à un endpoint dédié, qui retourne un token signé, à durée de vie limitée, à transmettre ensuite dans l’en-tête Authorization de chaque requête.
curl -X POST https://exemple.fr/wp-json/jwt-auth/v1/token \
-d "username=clement&password=motdepasse"
// Réponse :
{
"token": "eyJhbGciOiJIUzI1NiJ9...",
"user_email": "clement@exemple.fr",
"user_nicename": "clement"
}Ce token s’utilise ensuite ainsi :
fetch( 'https://exemple.fr/wp-json/wp/v2/posts', {
headers: {
'Authorization': 'Bearer eyJhbGciOiJIUzI1NiJ9...',
},
} );La configuration exige une clé secrète définie dans wp-config.php :
define( 'JWT_AUTH_SECRET_KEY', 'une-cle-longue-et-aleatoire' );
define( 'JWT_AUTH_CORS_ENABLE', true );Comparatif détaillé
| Critère | Mots de passe d’application | JWT (plugin tiers) |
|---|---|---|
| Disponibilité | Native depuis WordPress 5.6 | Nécessite un plugin tiers |
| Mise en place | Génération depuis le profil, aucune configuration serveur | Installation du plugin, clé secrète à définir |
| Durée de vie | Illimitée jusqu’à révocation manuelle | Limitée, expiration configurable |
| Révocation | Individuelle, immédiate depuis l’administration | Dépend de l’implémentation du plugin |
| Maintenance | Aucune, fait partie du cœur | Suivi des mises à jour du plugin nécessaire |
| Cas d’usage privilégié | Intégration serveur à serveur, scripts, CMS headless | Application mobile ou SPA avec session utilisateur limitée dans le temps |
Quand choisir les mots de passe d’application
Pour la grande majorité des projets headless que nous rencontrons, un frontend Next.js ou équivalent qui interroge WordPress en tant que source de contenu, les mots de passe d’application constituent le choix le plus simple et le plus robuste. Aucune dépendance supplémentaire, pas de clé secrète à faire circuler dans les variables d’environnement d’un plugin tiers, une révocation immédiate en cas de doute.
- Site headless dont le frontend agit comme un client de confiance (build serveur, service de revalidation)
- Scripts d’intégration ou de synchronisation entre systèmes
- Projets où la simplicité de maintenance prime sur la granularité de l’expiration
Quand JWT reste pertinent
JWT garde un avantage net dans un scénario précis : une application cliente, mobile ou web, où de vrais utilisateurs finaux se connectent directement avec leurs identifiants, et où l’on souhaite des tokens à courte durée de vie, renouvelés via un mécanisme de refresh token. Un mot de passe d’application, conçu pour une intégration plus stable, n’a pas de mécanisme d’expiration automatique natif, ce qui le rend moins adapté à ce contexte.
La question à se poser n’est pas « quelle est la méthode la plus moderne », mais « qui s’authentifie, et pour combien de temps ». Un service qui tourne en continu sur un serveur n’a pas les mêmes besoins qu’une application mobile installée sur le téléphone d’un utilisateur final.
Notre recommandation
Sur nos projets, la règle par défaut est simple : mots de passe d’application pour toute intégration serveur à serveur, JWT réservé aux cas où une vraie gestion de session utilisateur côté client est nécessaire, avec expiration courte et renouvellement. Cette règle couvre l’écrasante majorité des projets headless WordPress rencontrés en 2021, et évite d’ajouter une dépendance à un plugin tiers quand le cœur suffit largement.
En résumé
Aucune de ces deux méthodes n’est un choix par défaut universel. Les mots de passe d’application l’emportent par leur simplicité et leur intégration native pour la majorité des projets headless. JWT garde sa place pour les applications avec de vrais utilisateurs finaux et un besoin d’expiration fine des accès. Dans les deux cas, HTTPS reste un prérequis absolu en production, sans exception.
