Guida all'autenticazione della REST API di WordPress

Introduzione all'autenticazione della REST API di WordPress

La REST API di WordPress è uno strumento potente che consente di accedere ai contenuti e alle funzionalità di WordPress tramite richieste HTTP da qualsiasi applicazione, che si tratti di un'app mobile, di un frontend JavaScript, di un servizio esterno o di un'applicazione web completamente separata. Tuttavia, mentre la lettura dei contenuti pubblici è di solito disponibile senza autenticazione, la creazione, l'aggiornamento e l'eliminazione dei contenuti richiedono che l'utente si autentichi, in modo che WordPress sappia chi sta eseguendo l'azione e se dispone delle autorizzazioni necessarie.

WordPress supporta diversi metodi di autenticazione per la REST API, ognuno con i propri vantaggi, svantaggi e scenari d'uso ideali. La scelta del metodo giusto dipende da chi accede all'API (frontend sullo stesso sito, applicazione esterna, applicazione mobile), dal livello di sicurezza richiesto e dalla complessità dell'integrazione che si desidera implementare. In questa guida esaminiamo nel dettaglio ciascun metodo con esempi pratici.

Autenticazione tramite cookie con nonce

L'autenticazione tramite cookie è il metodo predefinito per le richieste che provengono dal sito WordPress stesso, in genere dal codice JavaScript nel pannello di amministrazione o sul frontend. Quando l'utente ha effettuato l'accesso a WordPress, il browser invia automaticamente un cookie con ogni richiesta e la REST API di WordPress lo utilizza per identificare l'utente. Tuttavia, il cookie da solo non è sufficiente, perché ciò renderebbe possibili attacchi CSRF, in cui un sito malevolo potrebbe attivare richieste per conto dell'utente loggato.

Come funziona il nonce

WordPress utilizza il nonce (number used once) come ulteriore livello di protezione contro gli attacchi CSRF. Il nonce è un token a tempo limitato che WordPress genera per l'utente loggato e che deve essere inviato con ogni richiesta che modifica i dati (POST, PUT, DELETE). Il codice JavaScript lo ottiene tramite la funzione wp_localize_script() o la variabile globale wpApiSettings.nonce nel pannello di amministrazione.

• Generazione - wp_create_nonce('wp_rest') sul lato server
• Passaggio - wp_localize_script() per passare il nonce a JavaScript
• Invio - header X-WP-Nonce o parametro di query _wpnonce
• Validità - il nonce scade dopo 24 ore (due periodi di validità del nonce di WordPress da 12h)
• Rinnovo - per le sessioni di lunga durata, richiedere periodicamente un nuovo nonce tramite l'API

L'autenticazione tramite cookie è ideale per il codice JavaScript eseguito sul sito WordPress stesso, perché non richiede alcuna configurazione aggiuntiva oltre al corretto passaggio del nonce. Non è adatta per le applicazioni esterne, perché queste non possono accedere al cookie di WordPress. Tieni inoltre presente che il nonce scade e che le sessioni di lunga durata richiedono un meccanismo di refresh del token, affinché l'utente non riceva un errore 403 nel bel mezzo del lavoro.

Application Passwords

Le Application Passwords sono state introdotte in WordPress 5.6 come metodo integrato per autenticare le applicazioni esterne senza fornire la password principale dell'utente. Ogni utente può creare più application password con nomi descrittivi (ad esempio Mobile App, Zapier Integration, Custom Script) e ciascuna può essere revocata in modo indipendente senza influenzare le altre o la password principale dell'utente.

Creazione e utilizzo

L'application password si crea nel pannello di amministrazione di WordPress sotto Utenti, Modifica utente, sezione Application Passwords. Si inserisce il nome dell'applicazione e WordPress genera una password di 24 caratteri suddivisa in 4 gruppi di 6 caratteri separati da uno spazio. Questa password viene utilizzata per l'HTTP Basic Authentication, in cui nome utente e application password vengono inviati nell'header Authorization codificati in formato base64.

Una richiesta con Application Password ha l'aspetto di un classico HTTP Basic Auth: l'header Authorization contiene Basic seguito dalla stringa username:application_password codificata in base64. Gli spazi nella password vengono ignorati, quindi puoi rimuoverli o lasciarli. WordPress riconosce automaticamente che si tratta di un'Application Password e non della password principale dell'utente e applica le autorizzazioni appropriate.

Vantaggi e limiti

• Semplicità - funzionalità integrata senza bisogno di plugin
• Controllo granulare - ogni applicazione ha la propria password che può essere revocata
• Registrazione - WordPress registra l'ultimo utilizzo di ciascuna application password
• Limite - funziona solo tramite HTTPS, perché il Basic Auth invia le credenziali in ogni richiesta
• Limite - nessuna granularità di scope o di autorizzazioni oltre al ruolo dell'utente

Le Application Passwords sono una scelta eccellente per le integrazioni server-to-server, ideali per gli ambienti di hosting VPS, per gli script di automazione e per le applicazioni in cui la semplicità è più importante del controllo granulare degli accessi. Usa sempre l'HTTPS, perché le credenziali vengono inviate in ogni richiesta e senza HTTPS possono essere intercettate. Per le integrazioni di produzione, crea un utente WordPress separato con il minimo delle autorizzazioni necessarie invece di usare un account amministratore.

OAuth 2.0

OAuth 2.0 è uno standard di settore per l'autorizzazione utilizzato da Google, Facebook, GitHub e da molti altri servizi. WordPress non offre un supporto OAuth integrato, ma è disponibile tramite plugin come WP OAuth Server e OAuth 2.0 Provider. OAuth è ideale negli scenari in cui vuoi consentire ad applicazioni di terze parti di accedere alla tua API WordPress con un controllo preciso delle autorizzazioni e senza condividere le credenziali degli utenti.

Il flusso OAuth 2.0

Il flusso OAuth più comune per le applicazioni web è l'Authorization Code flow, composto da diversi passaggi. L'applicazione reindirizza l'utente all'endpoint authorize di WordPress, dove l'utente approva l'accesso. WordPress reindirizza l'utente all'applicazione con un authorization code. L'applicazione scambia il codice con un access token chiamando l'endpoint token. L'access token viene quindi utilizzato per le richieste API nell'header Authorization Bearer.

• Authorization Code - il flusso più sicuro per le applicazioni web con un lato server
• Implicit - per le applicazioni SPA senza server (meno sicuro, di solito sconsigliato)
• Client Credentials - per la comunicazione server-to-server senza contesto utente
• PKCE - Proof Key for Code Exchange, migliora la sicurezza per le applicazioni mobile e SPA

OAuth offre il massimo livello di controllo e sicurezza, ma è anche il più complesso da implementare. Gli access token hanno una durata limitata e i refresh token vengono utilizzati per ottenerne di nuovi senza dover riautorizzare l'utente. Il parametro scope definisce quali autorizzazioni l'applicazione richiede, garantendo all'utente trasparenza su ciò che l'applicazione può fare con i suoi dati.

JWT (JSON Web Tokens)

L'autenticazione JWT è un'alternativa molto diffusa per l'accesso alla REST API, che utilizza token al posto delle sessioni. Un token JWT è una stringa firmata che contiene informazioni sull'utente e sulle autorizzazioni, inviata nell'header Authorization di ogni richiesta. WordPress non offre un supporto JWT integrato, ma è disponibile tramite plugin come JWT Authentication for WP REST API e Simple JWT Login.

Come funziona il JWT

L'utente invia nome utente e password all'endpoint del token (di solito /wp-json/jwt-auth/v1/token) e riceve in risposta un token JWT. Questo token viene poi inviato nell'header Authorization: Bearer di tutte le richieste API. Il server verifica la firma del token ed estrae le informazioni sull'utente senza dover interrogare il database, il che rende il JWT più efficiente per le API ad alto carico.

Il token JWT è composto da tre parti separate da punti: header (algoritmo e tipo di token), payload (dati dell'utente, tempo di scadenza, emittente) e signature (firma crittografica che garantisce l'integrità del token). Il token può essere decodificato lato client, ma non può essere falsificato senza la chiave segreta nota solo al server. Questo consente al client di leggere le informazioni sull'utente direttamente dal token, senza una chiamata API aggiuntiva.

Vantaggi del JWT

• Stateless - il server non memorizza le sessioni, facilitando la scalabilità
• Self-contained - il token contiene tutte le informazioni necessarie sull'utente
• Cross-domain - funziona con domini diversi senza i problemi CORS legati ai cookie
• Applicazioni mobile - ideale per le app mobile che non usano i cookie
• Prestazioni - la verifica del token non richiede l'interrogazione del database

Confronto tra i metodi di autenticazione

La scelta del metodo di autenticazione dipende dal tuo scenario specifico. Cookie e nonce sono ideali per JavaScript sullo stesso sito, perché non richiedono configurazioni aggiuntive. Dai un'occhiata ai nostri piani di hosting WordPress per un ambiente ottimale. Le Application Passwords sono la soluzione migliore per le semplici integrazioni server-to-server e per gli script, perché sono integrate e facili da usare. OAuth 2.0 è la scelta giusta per le applicazioni di terze parti, in cui servono un controllo granulare degli accessi e l'autorizzazione dell'utente. Il JWT è ottimale per le applicazioni mobile e per i framework SPA che comunicano con WordPress come headless CMS.

Raccomandazioni di sicurezza

• Usa sempre l'HTTPS - tutti i metodi di autenticazione richiedono una connessione crittografata
• Autorizzazioni minime - crea utenti con solo le autorizzazioni necessarie per l'accesso all'API
• Rotazione dei token - implementa i refresh token e una breve scadenza degli access token
• Rate limiting - limita il numero di richieste per utente come protezione dal brute-force
• Registrazione - registra tutte le richieste API per l'audit e il rilevamento di attività malevole
• Configurazione CORS - limita l'accesso all'API solo dai domini consentiti

Per le applicazioni di produzione consigliamo una combinazione di più metodi, in cui ognuno copre uno scenario diverso. Autenticazione tramite cookie per le interazioni nel pannello di amministrazione e sul frontend, Application Passwords per gli script interni e l'automazione, JWT per le applicazioni mobile e OAuth per le integrazioni di terze parti. Rivedi regolarmente i token attivi e le application password e revoca quelli non più in uso, perché ogni token attivo è un potenziale vettore d'attacco.