Skip to Content
WordPressPartie 9 — REST API & WordPress headless (Next.js)Authentification (tokens, nonces)

Chapitre 9.2 — Authentification (tokens, nonces)

⏱️ TL;DR — Lire du contenu public ne demande pas d’auth. Mais écrire, ou lire du non-public (brouillons, données privées), oui. Trois méthodes selon le contexte : nonce cookie (wp_rest) pour du JS même origine (vos blocs, ch. 8.7) ; Application Passwords (natif) pour un serveur/app externe (auth HTTP Basic sur HTTPS) ; JWT (via plugin) pour un flux à jetons. Règle d’or headless : l’authentification se fait côté serveur (dans votre backend Next.js), jamais en exposant des identifiants au navigateur.

🎯 Objectifs

  • Choisir la bonne méthode d’authentification selon le contexte.
  • Utiliser le nonce wp_rest (JS même origine).
  • Configurer et utiliser les Application Passwords.
  • Garder les secrets côté serveur en headless.

1. Public vs authentifié

  • Lecture publique : GET /wp/v2/posts (statut publish) → pas d’auth.
  • Écriture (POST/PUT/DELETE) ou lecture privée (brouillons, context=edit, meta protégées) → auth requise.

2. Le nonce cookie (wp_rest) — JS même origine

Quand votre JavaScript tourne dans WordPress (blocs, admin), l’utilisateur est déjà connecté par cookie ; il suffit d’ajouter un nonce pour prouver l’intention (anti-CSRF, ch. 7.7). C’est ce que @wordpress/api-fetch fait automatiquement (ch. 8.7) :

import apiFetch from '@wordpress/api-fetch';
// Le nonce 'wp_rest' est injecté automatiquement par WordPress (wp.apiFetch)
await apiFetch( { path: '/wp/v2/posts/42', method: 'POST', data: { title: 'Nouveau titre' } } );

En dehors de api-fetch, on passe le nonce en en-tête X-WP-Nonce (fourni via wp_localize_script, ch. 6.4). Le nonce ne marche que même origine (cookie de session) — donc pas pour un front Next.js sur un autre domaine.

3. Application Passwords — serveur/app externe

Les Application Passwords (natifs depuis WP 5.6) génèrent un mot de passe dédié (révocable) par utilisateur, pour une application. On authentifie en HTTP Basic (sur HTTPS obligatoire) :

curl -u "utilisateur:xxxx xxxx xxxx xxxx xxxx xxxx" \
     https://monsite.com/wp-json/wp/v2/posts?status=draft
  • Généré dans Utilisateurs → Profil → Mots de passe d’application.
  • Révocable individuellement (sans changer le mot de passe principal).
  • Les capabilities de l’utilisateur s’appliquent (créez un compte de service avec le rôle minimal nécessaire — moindre privilège, ch. 2.2).

⚠️ Piège n°1 — HTTP Basic sans HTTPS. Les Application Passwords transitent en Basic : sans HTTPS, les identifiants circulent en clair. Jamais en HTTP. WordPress refuse d’ailleurs de les activer hors contexte sécurisé.

4. JWT (via plugin)

Pour un flux à jetons (login → token → requêtes авec Authorization: Bearer …), on installe un plugin JWT (il n’y a pas de JWT natif dans le cœur). Utile pour des apps mobiles ou des architectures à tokens. Vérifiez la maintenance et la sécurité du plugin choisi (signature, expiration, refresh).

MéthodeContexte idéalNatif ?
Nonce wp_restJS même origine (blocs, admin)✅
Application PasswordsServeur/app externe, scripts, CI✅ (WP 5.6+)
JWTFlux à jetons (mobile, SPA)❌ (plugin)

5. Règle d’or headless : auth côté serveur

En headless (front Next.js), la règle absolue :

  • Les identifiants (Application Password, token) vivent uniquement côté serveur (variables d’environnement sans NEXT_PUBLIC_), utilisés dans des route handlers/Server Components/server actions.
  • Jamais dans le bundle client (le navigateur), jamais dans une variable NEXT_PUBLIC_*.
  • Le navigateur parle à votre backend Next.js (proxy), qui parle à WordPress avec les identifiants — CORS et secrets restent côté serveur.

⚠️ Piège n°2 — le secret dans le bundle. Une variable NEXT_PUBLIC_WP_TOKEN est inlinée dans le client → visible par tous. Utilisez une variable serveur (WP_APP_PASSWORD), lue seulement dans du code serveur. Si un secret a fuité, révoquez l’Application Password immédiatement. (Même leçon que le cours Moodle — c’est la erreur headless classique.)

💡 Pour un dev React — C’est exactement votre discipline Next.js : secrets en env serveur, jamais NEXT_PUBLIC_, appels authentifiés dans les Server Components/route handlers, le client ne voit que des données déjà filtrées. WordPress ne change rien à ce réflexe ; il fournit juste wp/v2 + Application Passwords comme back-office.

✏️ Exercices

  1. Votre bloc React (dans l’éditeur) doit enregistrer une donnée. Quelle auth, et qui la gère pour vous ?
  2. Un front Next.js sur app.exemple.com doit lire des brouillons de WordPress sur cms.exemple.com. Quelle méthode, et où mettez-vous les identifiants ?
  3. Pourquoi ne jamais utiliser un Application Password en HTTP simple ?

✅ Solution

  1. Le nonce wp_rest (auth par cookie de session + nonce anti-CSRF) : c’est du JS même origine, et @wordpress/api-fetch injecte le nonce automatiquement (ch. 8.7).
  2. Les Application Passwords (auth serveur/externe), avec les identifiants côté serveur Next.js (variable d’environnement sans NEXT_PUBLIC_), utilisés dans un Server Component/route handler. Le navigateur ne voit jamais le secret ; il passe par votre backend.
  3. Parce qu’ils transitent en HTTP Basic : sans HTTPS, les identifiants circulent en clair et peuvent être interceptés. HTTPS est obligatoire.

🧠 Quiz de révision

1. Faut-il s’authentifier pour lire du contenu public ?

Non : GET sur des ressources publiées est ouvert. L’auth sert pour l’écriture et le non-public.

2. Quelle auth pour du JS même origine (blocs) ?

Le nonce wp_rest (géré automatiquement par @wordpress/api-fetch).

3. Qu’est-ce qu’un Application Password ?

Un mot de passe dédié et révocable par application (WP 5.6+), utilisé en HTTP Basic sur HTTPS pour un accès serveur/externe.

4. Où placer les identifiants en headless ?

Côté serveur uniquement (env serveur, sans NEXT_PUBLIC_), dans les Server Components/route handlers.

5. Le nonce fonctionne-t-il pour un front sur un autre domaine ?

Non : il dépend du cookie de session même origine ; pour un domaine différent, on utilise Application Passwords/JWT côté serveur.

Chapitre suivant : Créer ses endpoints REST.

La REST API interneCréer ses endpoints REST