API REST WP: Configurare e utilizzare l'autenticazione OAuth 1.0 a

Italian (Italiano) translation by Piergiorgio Sansone (you can also view the original English article)

Nella parte precedente della serie, abbiamo impostato sul server l'autenticazione di base HTTP, installando il plugin disponibile su GitHub dal team API REST di WP. Il metodo di autenticazione di base ci permette di inviare le richieste di autenticazione inviando le credenziali d'accesso nell'intestazione della richiesta. Pur essendo veloce e pratico, c'è anche la possibilità che queste credenziali possano cadere in mani sbagliate. Quindi questo metodo deve essere utilizzato solo su reti sicure e solo per lo sviluppo e il test.

Per utilizzare l'autenticazione su server di produzione, è necessario utilizzare modi più sicuri per inviare richieste di autenticazione senza rischiare di esporre le credenziali di accesso. Grazie al metodo di autenticazione OAuth, queste richieste possono essere inviate senza esporre utente e password in modo non sicuro.

In questa parte della serie, impareremo ad impostare ed utilizzare il metodo di autenticazione OAuth ed utillizzarlo con il plugin REST API di WP. Per essere precisi, ci impegniamo a:

fare una panoramica del metodo di autenticazione OAuth e vedere come funziona
installare il plugin server OAuth
generare un token di accesso OAuth da utilizzare nella nostra applicazione

Cominciamo con la nostra introduzione per il metodo di autenticazione OAuth.

Introducendo l'autenticazione OAuth

Che cosa fate quando dovete accedere al vostro account Admin di WordPress? Semplicemente andate sulla vostra pagina di accesso ed inserite le credenziali di accesso , giusto? Che è semplice! Ma cosa accade quando usate un servizio di terze parti che fa la richiesta di accesso alle vostre risorse WordPress (post, pagine , media o altro)? Semplicemente consegnereste le credenziali di accesso a tale servizio, sapendo che potrebbero finire in mani sbagliate quando l'integrità di tale servizio è compromessa? La risposta sarebbe probabilmente "No".

Nel modello di autenticazione tradizionale, ci sono due ruoli:

Il Cliente: può essere un utente, applicazione o servizio
Il Fornitore delle risorse: il server dove si trovano le risorse protette

Se un client desidera accedere alle risorse protette, lui o lei sarebbe ottenere autenticata fornendo credenziali appropriate per il server e sarebbe essere concesso l'accesso.

Il problema si pone quando un servizio di terze parti ha bisogno di accedere a queste risorse protette sul server. A questo servizio non possono essere (e non dovrebbero essere) assegnate le credenziali dell'utente per accedere alle risorse. Fornire le credenziali ad una terza parte significa cedergli completamente il controllo su tutte le risorse presenti nel server.

Qui è dove la metodologia di autenticazione OAuth ci viene in soccorso. Questa introduce un nuovo ruolo nel processo di autenticazione ed è il proprietario delle risorse (resource owner). Adesso ci sono tre ruoli nel processo di autenticazione :

Il Cliente: non l'utente stesso ma un applicazione di terze parti o un servizio che agisce per conto dell'utente e accede a risorse protette.
Il server : Il server dove sono localizzate le risorse protette.
Il proprietario delle risorse : l'utente stesso.

I tre ruoli insieme fanno quello che viene definito come l'autenticazione OAuth a tre zampe. Il numero di gambe definisce i ruoli coinvolti in un processo di autenticazione. Quando il proprietario della risorsa è anche il client, il flusso diventa noto come autenticazione a due zampe.

Secondo Webopedia:

OAuth è un sistema di autorizzazione aperta standard utilizzata per fornire accesso sicuro alle applicazioni client alle risorse del server. Il framework di autorizzazione OAuth consente ad un'applicazione di terze parti l'accesso limitato al servizio HTTP o per conto del proprietario della risorsa o all'applicazione di terze parti, per ottenere l'accesso per proprio conto.

OAuth consente ai proprietari del server di autorizzare l'accesso alle risorse del server senza la condivisione delle credenziali. Questo significa che l'utente ha accesso a risorse private da un server all'altro senza condividere la propria identità.

Quindi nel flusso di autenticazione OAuth, l'utente non ha bisogno di esporre le credenziali ma può autorizzare il client ad agire per suo conto, e decidere a quali risorse il client può accedere. In altre parole, pur non dando le credenziali di accesso, l'utente può anche decidere l'ambito dell'accesso che al client sarà concesso.

In questo modo non solo siti Web, ma anche applicazioni desktop e mobile possono ottenere l'accesso limitato a una risorsa su un server.

In termini di WordPress, OAuth informa il Fornitore delle risorse (l'installazione WordPress) che il proprietario delle risorse (l'utente WordPress) possiede i diritti per accedere all'applicazione di una parte terza per accedere alle proprie risorse. Queste risorse possono essere qualsiasi cosa come post, pagine, tassonomia e supporti, ecc. Quest' autorizzazione può essere per l'accesso completo o limitato, come vedremo più avanti in questo tutorial.

Come funziona il flusso di autenticazione OAuth.

L' API autenticazione OAuth per WordPress è costruita sulle specifiche di OAuth 1.0a, quindi vedremo come funziona OAuth 1.0a.

OAuth funziona utilizzando le credenziali token rilasciate dal provider delle risorse (il server), su richiesta del proprietario della risorsa dopo che si è autenticato utilizzando le proprie credenziali. Questi token — associati al proprietario di risorse — vengono quindi utilizzati dal client (un'applicazione di terze parti o servizio) per accedere alle risorse protette.

Queste credenziali token hanno una durata limitata e possono essere revocate dal server su richiesta del proprietario della risorsa.

Il flusso di OAuth va come segue:

Il client invia una richiesta firmata al server per ottenere un Token di richiesta, noto anche come credenziali temporanee. Questa richiesta viene inviata all'endpoint credenziali temporanee URI, e contiene le seguenti operazioni:
- oauth_consumer_key: fornito dal server
- oauth_timestamp
- oauth_nonce
- oauth_signature
- oauth_signature_method
- oath_callback
- oauth_version (opzionale)
Il server verifica la richiesta e se è valido, concede un Token di richiesta che contienga:
- oauth_token
- oauth_token_secret
- oauth_callback_confirmed
Il client invia quindi il proprietario della risorsa (l'utente) al server per autorizzare la richiesta. Questo viene fatto mediante la costruzione di un URI di richiesta aggiungendo oauth_token ottenuti nel passaggio precedente per l'endpoint di autorizzazione del proprietario risorsa URI.
Proprietario della risorsa (l'utente) autorizza il server fornendo le credenziali.
Se il oauth_callback URI è stato fornito nel primo passaggio, il server reindirizza il client a quell'URI e aggiunge quanto segue come stringa di query:
- oauth_token: ottenuti nel secondo passaggio
- oauth_verifier: utilizzata per garantire che il proprietario della risorsa che ha concesso l'accesso è lo stesso restituito al client
Se il oauth_callback URI non è stato fornito nel primo passaggio, il server visualizza il valore della oauth_verifier in modo che il proprietario della risorsa possa informare il client manualmente.
Dopo aver ricevuto il oauth_verfier, il client richiede al server per le credenziali token inviando una richiesta all'endpoint del Token richiesta URI. Questa richiesta contiene le seguenti operazioni:
- oauth_token: ottenuti nel secondo passaggio
- oauth_verfier: ottenuti nel passaggio precedente
- oauth_consumer_key: fornito dal provider di risorse (il server), prima di iniziare il contatto (handshake) con oauth
- oauth_signature
- oauth_signature_method
- oauth_nonce
- oauth_version
Il server verifica la richiesta e concede il seguente, conosciuto come credenziali di Token:
- oauth_token
- oauth_token_secret
Il client utilizza quindi le credenziali Token per accedere alle risorse protette sul server.

Le informazioni di cui sopra possono essere trasportate sia da una stringa di query accodata per richiedere gli URI o includendola nell'intestazione di autorizzazione, anche se quest'ultimo è consigliato a causa di una maggiore sicurezza.

Questo è un processo lungo e deve tener conto quando si sviluppano i propri clienti di interagire con le API. Lo scopo del cliente è quello di gestire tutto questo gergo e facilitare l'utente nel processo di autenticazione. Poiché si utilizzerà un pacchetto fornito dal team di API REST di WP, i dettagli di cui sopra potranno essere astratti e saremo in grado di ottenere le credenziali token in un numero minimo di passaggi.

Nella discussione di cui sopra, abbiamo incontrato tre endpoint URIs, vale a dire:

L'endpoint della richiesta delle credenziali temporanee
L'endpoint dell'autorizzazione del proprietario della risorsa
L'endpoint del token di richiesta delle credenziali

Questi URI sono forniti dal server in vari modi. Uno di questi modi è esponendoli nella risposta del server quando si verifica per l'API. L'autenticazione OAuth API per WordPress API REST utilizza lo stesso metodo, come vedremo nella prossima sezione.

Dopo aver esaminato come funziona OAuth, il nostro prossimo passo è quello di installare e attivare l'autenticazione OAuth API per WordPress.

Installare l'autenticazione OAuth API per WordPress

L'autenticazione OAuth API per WordPress consente al server di accettare le richieste autenticate mediante l'implementazione di OAuth. Si basa sulle specifiche di OAuth 1.0 e le estende con un parametro aggiuntivo — wp_scope — per essere inviati all'endpoint di richiesta delle credenziali temporanee. Il parametro wp_scope definisce l'ambito di accesso concessa al client. Troverete maggiori informazioni nella documentazione ufficiale su GitHub.

Il plugin è disponibile su Github dal team di WP API REST e supporta solo la versione 4.4 o versioni successive di WordPress.

Copiate il plugin nella directory /wp-content/plugins/

1	$ git clone https://github.com/WP-API/OAuth1.git

Completato il download, attivatelo utilizzando WP CLI:

1	$ wp plugin activate OAuth1

In alternativa, è possibile anche attivarlo utilizzando la sezione admin del plugin di WordPress, se non desiderate usare WP CLI.

Questo è tutto ciò che è necessario per consentire al server di accettare OAuth come metodo di autorizzazione. La prossima cosa che dobbiamo fare è di inviare una richiesta al server per verificare se OAuth API è pronto per essere utilizzato.

Valutare la disponibilità di OAuth API

Prima si procede ad avviare l'handshake di OAuth, dovremmo prima controllare se l'API è attivata sul server. Ciò avviene inviando una semplice richiesta GET per la /wp-json/endpoint e quindi analizzando la risposta inviata dal server.

Accendi il tuo client HTTP e inviare una richiesta all'endpoint /wp-json/ come segue:

1	GET http://your-dev-server/wp-json/

Questo restituirà una risposta JSON come segue:

Il nostro obiettivo qui è il valore di oauth1 nel valore della proprietà di autenticazione. Questo oggetto ha le seguenti proprietà definite:

request: L'endpoint della richiesta delle credenziali temporanee
authorize: L'endpoint di autorizzazione del proprietario delle risorse
access: l'endpoint di richiesta del Token
version : la versione di OAuth utilizzato

I primi tre di loro sono URL assoluti che abbiamo incontrato quando abbiamo imparato a conoscere il meccanismo di OAuth nella sezione precedente.

L'oggetto di oauth1 definito nel valore della proprietà di autenticazione dimostra che l'API di OAuth è stata attivata con successo per il nostro sito WordPress e possiamo iniziare ad usarlo.

Se l'API di OAuth non è attivata per un sito, la risposta del server contiene un valore di proprietà di autorizzazione vuota come segue:

Ora che abbiamo installato il plugin OAuth1.0a, vediamo come possiamo creare e gestire i consumatori per le nostre applicazioni.

Creazione e gestione di applicazioni

Una volta che il plugin di OAuth1.0 è stato installato correttamente, possiamo creare e gestire i clienti per le nostre applicazioni utilizzando il profilo Admin di WordPress e quindi andando nella sezione Utenti > Applicazioni

Su questa pagina delle Applicazioni Registrate, siamo in grado di registrare una nuova applicazione facendo clic sul pulsante Aggiungi nuovo e quindi compilando i seguenti tre campi nella pagina risultante:

Nome del cliente: il nome del cliente Questo nome viene visualizzato all'utente durante il processo di autorizzazione e in seguito, sulle loro pagine del profilo nella sezione Applicazioni Autorizzate.
Descrizione: La descrizione facoltativa per l'applicazione del cliente.
Callback URL: L'URL di callback. Questo URL di callback viene utilizzato durante la generazione di credenziali temporanee come vedremo nel prossimo passaggio.

Una volta creata facendo clic sul pulsante Salva Cliente, i parametri Cliente Chiave e Cliente Segreto appariranno nella parte inferiore della pagina per questo particolare Cliente.

Questi parametri Cliente Chiave e Cliente Segreto agiscono rispettivamente come parametri di oauth_consumer_key e oauth_consumer_secret.

Nuovo Cliente segreto può essere creato facendo clic sul pulsante Rigenera Segreto nella parte inferiore della pagina.

Il plugin di OAuth espone anche la funzionalità per la creazione di un cliente nella console attraverso il plugin WP CLI. Così un nuovo consumatore possa essere creato anche con il seguente comando sul terminale:

1	wp oauth1 add --name=<consumer_name> --description=<consumer_description>

Questo cliente appena creato verrà quindi visualizzato nella pagina Applicazioni Registrate dove è possibile modificarlo.

Dopo aver registrato la nostra applicazione, siamo pronti per iniziare il processo di autorizzazione OAuth nelle sezioni seguenti.

Installare il Client CLI

Nota : al momento della stesura di questo tutorial, il plugin OAuth1.0a non supporta più il pacchetto Client CLI. Il pacchetto Client CLI potrebbe essere aggiornato in un prossimo futuro per lavorare con l'ultima versione del plugin OAuth, ma per ora, fate riferimento alla sezione successiva sulla generazione delle credenziali di OAuth utilizzando un client HTTP.

Il pacchetto Client-CLI dal team API REST WP permette l'interazione remota con un sito WordPress con WP-CLI e API REST di WP. Il codice sorgente è disponibile su GitHub.

Per utilizzare questo pacchetto, sarà necessario che siano installati e attivati sul server dove si trova la vostra installazione di WordPress i seguenti pacchetti:

WP CLI
Il plugin WP REST API
Il server plugin OAuth 1.0a

Nella macchina (o client), da cui si desidera generare le richieste, deve essere installato quanto segue:

WP CLI
Composer
Il repository del Client CLI

Troverete le istruzioni per installare i pacchetti di cui sopra sui loro rispettivi siti.

Detto questo, cerchiamo di copiare il repository sul client eseguendo il seguente comando:

1	$ git clone https://github.com/WP-API/client-cli

Ora navigate nella directory copiata e installate le dipendenze del pacchetto utilizzando il Composer:

1	$ cd client-cli
2	$ composer install

Se tutto va bene, la riga di comando dovrebbe mostrare qualcosa di simile a quanto segue:

Ora che abbiamo installato il pacchetto, siamo pronti per generare le credenziali token e interagire in remoto all'API REST di WordPress tramite OAuth.

Utilizzo del Client CLI per generare le credenziali OAuth

Per avviare il processo di autorizzazione OAuth, otteniamo in primo luogo dal server le seguenti :

oauth_consumer_key
oauth_consumer_secret

Questo può essere generato dirigendo il terminale alla vostra directory di installazione di WordPress sul server ed eseguendo il seguente comando CLI WP:

1	$ wp oauth1 add

Questo genererà un output simile al seguente:

i codici Key e Secret ottenuti qui sono rispettivamente il oauth_consumer_key e oauth_consumer_secret .

Ora abbiamo bisogno di collegare il client al nostro sito WordPress. Sul client, passate alla directory client-cli che avete copiato nella sezione precedente ed eseguite il seguente comando:

1	$ wp --require=client.php api oauth1 connect http://your-dev-server/ --key=<your key here> --secret=<your secret here>

Sostituite l'URL e anche la chiave e il segreto che è stato ottenuto nel passaggio precedente nel comando precedente. L'output dovrebbe essere simile al seguente:

$ wp --require=client.php api oauth1 connect http://localserver/wordpress-api/ --key=kXZMTt3O5hBZ --secret=ueDNeCfgNuyNyxkiU3qHGgWZWmGsg5lZwmMyhyjANsyYgz3Q

Open in your browser: http://localserver/wordpress-api/oauth1/authorize?oauth_token=wFxrd8OzcIL6lSRkLmmvViIe

Enter the verification code:

Passate all'URL fornita dal server e autenticatevi facendo clic sul pulsante Autorizza:

Nella schermata successiva, vi presenterete con il token di verifica (o la oauth_verifier):

Copiate il verificatore e incollatelo nel vostro terminale. Riceverete una Key e un Secret code, che sono fondamentalmente i vostri oauth_token e oauth_token_secret:

È possibile utilizzare queste credenziali token nel tuo client HTTP o qualsiasi altra applicazione che supporta l'invio di richieste autenticate utilizzando l'API di OAuth.

Utilizzando un Client HTTP per generare le credenziali OAuth

Poiché il plugin server OAuth 1.0a segue il flusso a tre gambe, la creazione delle credenziali di OAuth prevede tre passaggi:

Acquisizione delle credenziali temporanee
Autorizzazioni utente
Cambio token

Iniziamo ad implementare tutti i passaggi sopra utilizzando un client HTTP, vale a dire Postman.

1. Acquisizione delle credenziali temporanee

Per acquisire le credenziali temporanee, inviamo una richiesta POST per l'endpoint /oauth1/request. Questo endpoint per la richiesta delle credenziali temporanee dovrebbe essere scoperto come un server ma potrebbe sostituire questo percorso con il suo. In una sezione precedente abbiamo visto anche la funzionalità di individuazione automatica mentre valuta la disponibilità dell'API OAuth .

La richiesta POST dovrebbe includere i parametri oauth_consumer_key e oauth_consumer_secret come acquisito durante la registrazione di un cliente per l'applicazione. La richiesta potrebbe includere anche il parametro oauth_callback e questo URL di callback deve corrispondere il regime, host, port e percorso dell'URL richiamata che è stata fornita durante la registrazione dell'applicazione.

A parte i parametri oauth_consumer_key e oauth_consumer_secret, la richiesta deve includere anche i parametri oauth_signature e oauth_signature_method. Quando si utilizza Postman, il oauth_signature è generato automaticamente e abbiamo solo bisogno di specificare il parametro oauth_signature_method. Attualmente, solo il metodo di firma HMAC-SHA1 è supportato dal plugin server OAuth.

I parametri di cui sopra possono essere passati in uno dei tre modi seguenti:

Tramite intestazione dell'Authorizatione
Tramite i parametri della query (GET) nell'URL
Tramite parametri della richiesta del corpo (POST). Il tipo di contenuto in questo caso dovrebbe essere application/x-www-form-urlencoded.

Spetta a voi di utilizzare qualsiasi di questi metodi di cui sopra per inviare questi parametri al server.

Ora iniziamo il processo di accensione di Postman e inviando una richiesta POST per l'endpoint di richiesta delle credenziali temporanee. Ma prima di allora, copiate i parametri Key Consumer e Consumer Secret come fornito dall'applicazione appena registrata in quanto saranno necessari in questo passaggio.

ConfigurarePostman per inviare una richiesta POST per l'endpoint di credenziali token temporaneo. Quindi nella scheda Autorizzazioni, selezionare l'opzione di OAuth 1.0 nell'elenco a discesa. Compilate i campi chiave e segreto con i valori forniti dal cliente. Assicuratevi di controllare che l'opzione di firma del metodo è impostata su HMAC-SHA1.

Non abbiamo bisogno di immettere i valori diversi da questi. Fare clic sul pulsante di richiesta di aggiornamento, e infine invia la richiesta facendo clic sul pulsante Invia.

Se non c'è alcun errore, è necessario che il server restituirà un codice di stato OK 200 - insieme al corpo di risposta con un tipo di contenuto di application/x-www-form-urlencoded. Questo corpo di richiesta è simile alla seguente stringa di testo:

1	oauth_token=tyNCKaL3WAJXib5SI6jCnr4P&oauth_token_secret=1GiImP2XBacmk4FhcEFtqqENs3Bt6Q1m3zDf5s0Rk2kDJyTF&oauth_callback_confirmed=true

Questo corpo di risposta contiene tre parametri per il passaggio successivo del flusso a tre zampe. Questi tre parametri sono:

oauth_token: un token temporaneo di OAuth per la fase di autorizzazione.
oauth_token_secret: un segreto temporaneo da utilizzare con oauth_token.
oauth_callback_confirmed: questo parametro viene sempre restituito o meno che il parametro di oauth_callback non sia fornito nel primo passaggio.

Con queste credenziali temporanee pronte, siamo pronti per il passaggio di autorizzazione utente.

2. Autorizzazione Utente

Per il passaggio di autorizzazione utente, apriamo l'endpoint risorsa autorizzazione del proprietario nel browser e passiamo l' oauth_token e oauth_token_secret come ottenuti nel passaggio precedente come parametri di query simile alla seguente:

1	http://your-dev-server/oauth1/authorize?oauth_token=<token_here>&oauth_token_secret=<secret_here>

Il browser ti chiederà di accedere a WordPress (se non si è già connessi) e poi vi chiederà di autorizzare l'applicazione:

Qui Awesome Application è il nome dell'applicazione registrata.

Autorizzare l'applicazione facendo clic sul pulsante autorizza e vi si presenterà un codice di verifica nella schermata successiva:

Questo token agisce come il token di oauth_verifier nel passaggio successivo.

Una volta che l'utente ha autorizzato il client, l'applicazione verrà visualizzata nella sezione applicazioni autorizzate a utenti > pagina il tuo profilo.

3. Scambio di Token

Il prossimo e il passo finale nel flusso di tre zampe è scambio di token. In questo passaggio, i token temporanei ottenuti nel primo passaggio vengono scambiati per un token longevo che potrebbe essere utilizzato dal client.

Per avviare il processo di cambio token, tornate al Postman e configuratelo per inviare una richiesta POST per l'endpoint di richiesta di token.

Utilizzando nuovamente l'opzione di OAuth 1.0 nella scheda Autorizzazione, compilate i campi Key Consumer e Consumer Secret con valori come previsto da parte del consumatore. Per i campi di Token e Secret Token, utilizzare i valori dei parametri oauth_token e oauth_token_secret (credenziali temporanee) che sono stati ottenuti nel primo passaggio.

Cosi ci possiamo anche passare i parametri nell'URL come parametri di query, aggiungete il parametro di oauth_verifier all'URL come segue:

1	http://your-dev-server/oauth1/access?oauth_verifier=<oauth_verifier_value>

Con tutti i parametri a posto, Inviate la richiesta facendo clic sul pulsante Invia. Se tutto va bene, è necessario che il server restituisca un codice di stato 200 - OK insieme al corpo di risposta contenente i parametri oauth_token e oauth_token_secret.

1	oauth_token=<oauth_token_value>&oauth_token_secret=<oauth_secret_value>

A questo punto, i token temporanei acquistati nel primo passaggio vengono scartati e non possono più essere utilizzati.

Questi nuovi parametri oauth_token e oauth_token_secret rappresentano le credenziali di OAuth che è possibile utilizzare nel tuo client per generare le richieste autenticate.

L'invio di un Test di richiesta autenticata

Ora che abbiamo ottenuto le nostre credenziali token, possiamo inviare una richiesta di test al server utilizzando il Postman per vedere se funzionano (ovviamente lo faranno!).

Invieremo una richiesta di DELETE al server per eliminare un post con un id di 50. Questo id può essere diverso nel vostro caso.

Prima di iniziare sarà necessario avere il seguente :

oauth_consumer_key: ottenuti nel primo passaggio
oauth_consumer_secret: ottenuti nel primo passaggio
oauth_token: ottenuta nel passaggio finale
oauth_token_secret: ottenuta nel passaggio finale

Selezionare OAuth 1.0 dall'elenco a discesa sotto la scheda di Autorizzazione del Postman e riempire i primi quattro campi, come accennato in precedenza. Di seguito è quello che sembra:

Fare clic sul pulsante di richiesta di aggiornamento dopo aver compilato i campi. Controllando l'opzione Aggiungi parametri all'intestazione invia i parametri nell'intestazione della richiesta anziché aggiungerli in una stringa di query.

Inviata la richiesta dovreste ottenere codice di stato 200 - OK dal server, mostrando che il post è stato eliminato con successo.

Conclusione

In questa lunga esercitazione abbiamo fatto una panoramica del metodo di autenticazione OAuth e come funziona per fornire accesso sicuro a serzi ed applicazioni di terze parti delegate. Abbiamo anche istituito l'autenticazione OAuth API per WordPress sul server ed usata in combinazione con un client HTTP per ottenere credenziali token.

Nella parte successiva di questa serie, ci occuperemo del recupero del contenuto tramite l'API REST di WP. Quindi rimanete sintonizzati...