REST API authentication WordPress: application passwords, JWT e quando usare l'una o l'altra

La REST API di WordPress risponde a qualsiasi richiesta GET senza autenticazione — è così che un'app può leggere i post pubblici. Ma nel momento in cui l'integrazione deve scrivere — creare un post, aggiornare un prodotto, modificare un ordine — WordPress richiede un utente autenticato con i permessi giusti. È qui che la scelta del metodo di autenticazione diventa critica, perché ogni metodo ha un modello di sicurezza diverso.

L'errore più comune è usare le credenziali dell'admin per tutto. Funziona, ma significa che l'integrazione ha i permessi dell'admin: se il token o la password finisce in mani sbagliate, l'attaccante ha accesso completo al sito. Il principio del minimo privilegio vale anche per le API: l'integrazione dovrebbe usare un utente con i soli permessi necessari, non l'admin.

Application passwords: il metodo nativo

Le application passwords sono il metodo nativo di WordPress dalla 5.6: password monouso, generate dal profilo utente, revocabili singolarmente. Sono pensate per integrazioni esterne — un'app che posta, un CRM che legge — e usano Basic Auth. Sono semplici, non richiedono plugin, e ogni applicazione ha la sua password revocabile. Il limite è che sono legate a un utente: se l'utente viene cancellato, tutte le sue application passwords smettono di funzionare.

# Generare un application password (da WP-CLI o dal profilo utente)
wp user application-password create admin "Integrazione CRM" --user=admin
# Output: xxxx xxxx xxxx xxxx xxxx xxxx

# Usarla con Basic Auth via cURL
curl -u admin:xxxx\ xxxx\ xxxx\ xxxx\ xxxx\ xxxx \
  -X POST https://miosito.com/wp-json/wp/v2/posts \
  -H 'Content-Type: application/json' \
  -d '{"title":"Post via API","status":"draft"}'

# Verificare l'utente autenticato (chi sono io per l'API?)
curl -u admin:xxxx\ xxxx\ xxxx\ xxxx\ xxxx\ xxxx \
  https://miosito.com/wp-json/wp/v2/users/me

JWT: per le app stateless e i frontend separati

Il JWT — JSON Web Token — è il metodo per le integrazioni stateless e per i frontend separati (headless). L'utente si autentica una volta, riceve un token firmato, e lo presenta a ogni richiesta successiva. Il token ha una scadenza e può essere rinnovato con un refresh token. A differenza delle application passwords, il JWT non è legato a una sessione server-side: il server verifica la firma del token senza tenere stato.

Il JWT richiede un plugin (il più usato è JWT Authentication for WP REST API) e una chiave segreta in wp-config.php. La chiave è il cuore della sicurezza: se la conoscono, possono falsificare token per qualsiasi utente. Va in una variabile d'ambiente o in wp-config.php protetto, mai nel codice dell'app.

// wp-config.php — chiave segreta per JWT (plugin JWT Auth)
define( 'JWT_AUTH_SECRET_KEY', getenv( 'JWT_AUTH_SECRET_KEY' ) );

// Flusso: l'utente invia credenziali, riceve un token
// POST /wp-json/jwt-auth/v1/token  { "username": "...", "password": "..." }
// Risposta: { "token": "eyJ...", "user_email": "..." }

// Il token va nell'header Authorization per le richieste successive:
// Authorization: Bearer eyJ...

// Verificare il token server-side prima di fidarsi
add_filter( 'jwt_auth_token_before_dispatch', function( $data, $user ) {
    // Logica custom: es. limitare i permessi del token
    return $data;
}, 10, 2 );

Cookie auth: per i plugin e il frontend stesso WordPress

Il terzo metodo, la cookie auth, è per il codice che gira dentro WordPress stesso — plugin, temi, JavaScript nel frontend. Usa il cookie di sessione di WordPress e il nonce. Non serve per integrazioni esterne, perché il cookie è legato al dominio e alla sessione. Ma per una chiamata AJAX dal frontend al backend, è il metodo corretto: l'utente è già autenticato dal cookie, il nonce protegge dal CSRF.

La regola pratica: integrazione esterna server-side (CRM, app) → application passwords. Frontend separato o app mobile stateless → JWT. Codice dentro WordPress → cookie + nonce. Mescolare i metodi — usare il JWT dove basterebbe il cookie, o le application passwords dove serve il JWT — crea complessità inutile e superficie d'attacco. Un'integrazione API ben fatta sceglie un metodo, lo implementa correttamente, e lo documenta. Lo sviluppo personalizzato è la risposta quando l'integrazione ha requisiti che i metodi standard non coprono.