Mots de passe d’application (Application Passwords)
Définition : Les mots de passe d’application WordPress sont des identifiants propres à une intégration, distincts du mot de passe de connexion habituel. Ils servent notamment à authentifier des clients REST externes via HTTPS.
Comprendre et utiliser
À quoi sert cette notion ?
Ils permettent de révoquer une intégration sans changer le mot de passe principal du compte et d’identifier plus clairement l’usage d’un service automatisé.
Fonctionnement technique
Un client envoie l’identifiant WordPress et un mot de passe d’application par authentification HTTP Basic sur une connexion TLS. Les permissions restent celles du compte associé.
Dans quel contexte l’utiliser ?
Un outil interne autorisé récupère les brouillons WordPress d’un utilisateur responsable du contenu depuis un serveur séparé.
Étude de cas : application professionnelle
Une application externe ne doit pas utiliser le mot de passe principal du compte WordPress pour ses requêtes automatisées. Créer un mot de passe d’application dédié, le stocker dans un espace de secrets et imposer HTTPS. Tester l’accès avec un compte aux capacités minimales, puis révoquer le secret pour vérifier qu’il devient inutilisable. Cette procédure permet d’isoler une intégration et de réagir à sa compromission sans interrompre toutes les autres. Les mots de passe d’application ne contournent pas la permission_callback : le compte associé doit toujours être autorisé pour chaque opération.
Exemple technique commenté
Les lignes ci-dessus sont des exemples de requêtes HTTP, non des commandes prêtes à coller dans un article. Pour les essayer, utiliser un client HTTP et un site de test. Toute opération d'écriture nécessite un compte autorisé, une authentification appropriée et une sauvegarde du jeu de données concerné.
GET /wp-json/wp/v2/users/me
Authorization: Basic <identifiants encodés — exemple non réel>
Accept: application/jsonDécryptage du code et résultat attendu
La requête vise un endpoint lié à l’utilisateur authentifié. Le champ Authorization n’est qu’un emplacement de démonstration ; aucun secret fonctionnel n’est fourni.
Exercice guidé pour vérifier la notion
Créer une application de test avec un compte aux droits limités, vérifier l’accès à users/me puis révoquer son mot de passe et recommencer.
Précautions et limites
Ne jamais enregistrer le secret dans un fichier public, une URL ou un dépôt Git. Exiger HTTPS, limiter le compte aux capacités nécessaires et révoquer toute clé compromise.
À ne pas confondre
Le mot de passe d’application authentifie un client externe ; la nonce REST est conçue principalement pour les requêtes utilisant les cookies de session du navigateur.
Diagnostic avancé
En cas de 401, vérifier le secret, l’en-tête Authorization et le passage de cet en-tête à travers le proxy.
Choix d’architecture et déploiement
Prévoir un secret par intégration, une rotation documentée et une identité dotée du moindre privilège. Ne jamais attribuer des droits administrateur par commodité.
