# Mots de passe d’application : l’authentification REST simplifiée par WordPress 5.6

> WordPress 5.6 intègre nativement les mots de passe d'application. Voici pourquoi cette fonctionnalité change la donne pour l'authentification headless.

- Auteur : Clément Hadrot
- Publié le : 2021-02-03
- Mis à jour le : 2021-02-03
- Catégorie : Headless & API
- URL : https://wpmoderne.dev.wordpress-developpement.fr/headless/mots-de-passe-application-wordpress-5-6/

## L’essentiel

- Disponible en core depuis WordPress 5.6, décembre 2020
- Authentification HTTP Basic sans dépendance à un plugin tiers
- Révocable individuellement depuis le profil utilisateur

Décembre 2020 a marqué un tournant discret mais important pour l'écosystème headless WordPress. La version 5.6 a intégré au cœur une fonctionnalité jusque-là réservée à des plugins tiers ou à l'API XML-RPC historique : les mots de passe d'application. Une avancée qui simplifie considérablement l'authentification de l'API REST pour un usage headless, sans dépendre d'un plugin externe.

Nous avions détaillé, dans un précédent article, les limites de l'authentification par cookie et nonce pour un frontend véritablement découplé. Les mots de passe d'application répondent directement à ce manque, avec une approche pensée dès le départ pour des clients distants : applications mobiles, scripts d'intégration, et bien sûr frontends headless.

## Comment fonctionne cette authentification

Le principe est simple et repose sur un standard HTTP ancien et éprouvé : l'authentification HTTP Basic. Chaque utilisateur peut générer, depuis son profil dans l'administration WordPress (*Utilisateurs > Votre profil > Mots de passe d'application*), un mot de passe spécifique à une application, indépendant de son mot de passe de connexion habituel.

Ce mot de passe se présente sous un format reconnaissable, avec des espaces regroupant les caractères par blocs de quatre : `xxxx xxxx xxxx xxxx xxxx xxxx`. Il s'utilise ensuite en combinaison avec le nom d'utilisateur, encodé en base64 dans l'en-tête `Authorization` de chaque requête :

```
curl -X POST https://exemple.fr/wp-json/wp/v2/posts \
  -u "clement:xxxx xxxx xxxx xxxx xxxx xxxx" \
  -H "Content-Type: application/json" \
  -d '{"title":"Nouvel article","status":"draft"}'
```

Côté JavaScript, la même logique s'applique via l'en-tête `Authorization` avec le préfixe `Basic` :

```
const identifiants = btoa( 'clement:xxxx xxxx xxxx xxxx xxxx xxxx' );

fetch( 'https://exemple.fr/wp-json/wp/v2/posts', {
    method: 'POST',
    headers: {
        'Authorization': `Basic ${ identifiants }`,
        'Content-Type': 'application/json',
    },
    body: JSON.stringify( { title: 'Nouvel article', status: 'draft' } ),
} );
```

## Pourquoi c'est une vraie avancée pour le headless

Avant WordPress 5.6, un développeur qui voulait authentifier des requêtes REST depuis un serveur distant devait installer un plugin tiers, souvent « JWT Authentication for WP REST API » ou l'un de ses équivalents. Cela signifiait une dépendance supplémentaire à maintenir, à mettre à jour, et potentiellement à sécuriser soi-même.

Avec les mots de passe d'application intégrés au cœur, cette dépendance disparaît pour de nombreux cas d'usage. Aucune installation supplémentaire, aucune clé secrète à configurer manuellement dans un fichier de configuration : la fonctionnalité est disponible dès l'installation de WordPress, activée par défaut sur les sites accessibles en HTTPS.

- Aucun plugin tiers à installer ni à maintenir
- Révocation individuelle possible depuis le profil, sans changer le mot de passe principal
- Chaque mot de passe est nommé, ce qui facilite le suivi des intégrations actives
- Compatible avec l'authentification à deux facteurs, puisque distinct du mot de passe de connexion

> L'essentiel à retenir : Disponible en core depuis WordPress 5.6, décembre 2020 ; Authentification HTTP Basic sans dépendance à un plugin tiers ; Révocable individuellement depuis le profil utilisateur

## Précautions à respecter

Cette simplicité ne dispense pas de rigueur. Plusieurs points de vigilance s'imposent avant de déployer cette méthode en production.

### HTTPS obligatoire

WordPress désactive automatiquement les mots de passe d'application sur les sites qui ne sont pas servis en HTTPS, sauf en environnement local reconnu comme tel. C'est une protection essentielle : l'authentification HTTP Basic transmet les identifiants de façon lisible si le canal n'est pas chiffré, un HTTPS valide est donc un prérequis non négociable en production.

### Les permissions restent celles de l'utilisateur

Un mot de passe d'application hérite exactement des capacités du compte WordPress auquel il est rattaché. Générer un mot de passe d'application pour un compte administrateur, alors qu'un rôle « éditeur » suffirait pour l'intégration prévue, revient à donner bien plus de pouvoir que nécessaire à l'application distante.

> Créez systématiquement un compte utilisateur dédié à chaque intégration headless, avec le rôle strictement nécessaire, plutôt que de réutiliser un compte administrateur personnel. En cas de compromission du frontend, les dégâts restent contenus au périmètre de ce rôle.

### Révocation et rotation

Chaque mot de passe d'application peut être révoqué individuellement, sans affecter les autres intégrations ni le mot de passe principal du compte. Bonne pratique : nommer chaque mot de passe généré selon son usage (« Frontend Next.js production », « Script de synchronisation ») pour identifier rapidement quoi révoquer en cas de doute.

## En résumé

Les mots de passe d'application, natifs depuis WordPress 5.6, simplifient considérablement l'authentification REST pour un frontend headless : plus besoin de plugin tiers, une révocation granulaire, et une intégration au standard HTTP Basic bien connu. Le prochain article de cette série comparera cette méthode à l'authentification par JWT, pour trancher entre les deux selon le contexte de votre projet.