SaaS, REST e OAuth2: un semplice esempio

Sebbene questa dissertazione amisca a puntualizzare gli aspetti semantici ed astratti relativi all’attuale situazione del Cloud Computing, vale comunque la pena riportare un caso d’uso reale. In questo modo il lettore può apprendere e fissare meglio i concetti teorici trattati nei precedenti capitoli, nonché avere una visione d’insieme più completa e appropriata.

Si supponga di essere clienti di un servizio sviluppato con la filosofia SaaS che si occupa di fornire un servizio anagrafe online. In questo contesto, ai fini del- l’esempio, non è interessante approfondire come il servizio riesca ad interfacciarsi con l’utente (umano) finale (di solito mediante un interfaccia web, o un vero ap- plicativo desktop/mobile), piuttosto è interessante sapere che il servizio mette a disposizione una serie di API (lato server/backend) che possono essere interrogate da valide ed autenticate applicazioni di terze parti (registrate con il servizio). Ci è noto inoltre (in generale dalla documentazione) che il servizio anagrafico è stato sviluppato:

• usando la filosofia architetturale REST: implementandone i vincoli e sotto- vincoli più significativi (per chiarimenti fare riferimento alla sezione 2.1) • adottando il protocollo HTTP come meccanismo per il trasferimento delle

informazioni (per chiarimenti fare riferimento alla sezione 2.2)

• utilizzando il formato JSON come meccanismo per la strutturazione delle informazioni

• utilizzando di OAuth2 come framework per l’autorizzazione degli accessi (per chiarimenti fare riferimento alla sezione 2.3)

Conoscendo tecnologie e filosofie adottate dal servizio anagrafe, mettendosi nei panni dello sviluppatore intenzionato ad usare le API offerte dal servizio, si riesce ad avere una visione molto precisa su come procedere sia dal punto di vista implementativo, sia dal punto di vista di progettazione di un’applicazione client di terze parti che riesca ad interagire con il servizio stesso.

Si supponga quindi di avere a disposizione un’API (offerta dal servizio ana- grafe) per il recupero dei dati anagrafici delle persone fisiche in Italia. Secondo il protocollo astratto del framework OAuth2 2.3.2 , ogni risorsa protetta può esse- re acceduta mediante l’utilizzo di un access_token da presentare al server delle risorse (Resource Server). Il token a sua volta può essere richiesto al server delle autorizzazioni (Authorization Server) previo consenso del proprietario della ri- sorsa Resource Owner. La richiesta del token avviene specificando qual’è il tipo di flusso che si vuole usare (grant type) e, nel caso in questione, l’entità Client (in riferimento al protocollo 2.3.2) è l’applicazione di terze parti che si intende svi- luppare. Il grant appropriato (in riferimento a quanto brevemente analizzato in 2.3.3) è il client_credentials grant: ovvero il flusso che permette di ottenere il to- ken autenticando direttamente l’applicazione di terze parti in questione mediante un identificativo del client (client_id) e un segreto del client (client_secret).

Il protocollo si differenzia da quello astratto (in figura 2.6) nei punti A,B,C. Il consenso da parte del Resource Owner è infatti implicito (A e B non più necessari), mentre nel punto C vengono inviate direttamente le credenziali del client. Il protocollo esatto è riportato nella figura 3.2. Il modo in cui l’applicazione di terze parti riesca ad ottenere un client_id e un client_secret non rientra negli scopi dell’esempio, ma in generale, nelle situazioni reali viene usata una sorta di registrazione (gratuita o a pagamento in base alla tipologia di servizio offerto).

Dal punto di vista tecnico, un esempio di richiesta (e risposta) HTTP per l’acces_token (punti C e D della figura 3.2) è riportato nel listato 3.1. Si noti come la filosofia REST permetta al flusso richiesta/risposta di essere conciso, esplicativo e di facile interpretazione. Lo sviluppatore può implementare tale flusso con qualsiasi tecnologia e linguaggio richiesti dalla sua applicazione di terze parti permettendone l’evoluzione in maniera del tutto indipendente (disaccoppiamento tanto proposto da REST). In particolare inoltre:

Figura 3.2: OAuth2: client_credentials grant

• un token è identificato dalla risorsa http://anagrafica.it/oauth/token • le credenziali del client di terze parti vengono inviate usando l’autenticazione

HTTP di tipo Basic (header Authorization) suggerita e consigliata dallo standard OAuth2

• il tipo di grant viene identificato dal parametro grant_type di tipo application/x- www-form-urlencoded specificato nel corpo (body) della richiesta

• la risposta è di tipo JSON e contiene l’access_token, il tipo di token e il numero di secondi di validità

1 POST / oauth / token HTTP/1.1 2 Host : a n a g r a f i c a . i t

3 Authorization : Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW 4 Content Type : a p p l i c a t i o n /x www form urlencoded 5

6 grant_type=c l i e n t _ c r e d e n t i a l s 7

8

9 HTTP/1.1 200 OK

10 Content Type : a p p l i c a t i o n / j s o n ; c h a r s e t=UTF 8 11

12 {

13 " access_token ":"2 YotnFZFEjr1zCsicMWpAA" , 14 " token_type " : " Bearer " ,

16 }

Listato 3.1: Richiesta/risposta di un access token

Una volta ottenuto un valido access_token è possibile usufruire delle API offerte dal servizio anagrafe (punti E ed F della figura 3.2). Di seguito alcuni esempi di richieste e risposte. Anche in questo caso si noti come la filosofia REST permetta al flusso richiesta/risposta di essere conciso, esplicativo e di facile interpretazione. In particolare nel listato 3.2 si vuole la lista di tutte le persone nate a Pisa:

• la lista è una risorsa a tutti gli effetti identificata dall’URL http://anagrafica.it/data/persone?citta_nascita=Pisa

• viene usato il token precedentemente ricevuto come campo di Autorizzazio- ne (header Authorization) come dettato dalla filosofia OAuth2

• se l’autorizzazione va a buon fine, il contenuto della risposta è una lista di persone rappresentata nel formato JSON (array di oggetti)

1 GET / data / persone ? c i t t a _ n a s c i t a=Pisa HTTP/1.1 2 Host : a n a g r a f i c a . i t

3 Authorization : Bearer 2YotnFZFEjr1zCsicMWpAA 4

5

6 HTTP/1.1 200 OK

7 Content Type : a p p l i c a t i o n / j s o n ; c h a r s e t=UTF 8 8 9 [ { 10 "nome " : " Mario " , 11 "cognome " : " Rossi " , 12 . . . . . 13 } , 14 { 15 "nome " : " Matteo " , 16 "cognome " : " Bianchi " , 17 . . . . . 18 } 19 . . . . 20 ]

Un altro semplice esempio potrebbe essere la richiesta dei dati di una persona specificandone il codice fiscale. In tal caso richiesta e risposta potrebbero essere molto simili a quelli del listato 3.3.

1 GET / data / persone /RSSMRA85T10A562S HTTP/1.1 2 Host : a n a g r a f i c a . i t

3 Authorization : Bearer 2YotnFZFEjr1zCsicMWpAA 4

5

6 HTTP/1.1 200 OK

7 Content Type : a p p l i c a t i o n / j s o n ; c h a r s e t=UTF 8 8

9 {

10 "nome " : " Mario " , 11 "cognome " : " Rossi " ,

12 " c i t t a _ n a s c i t a " : " San Giuliano Terme " , 13 " p r o v i n c i a " : " PI " ,

14 " data_nascita ":"10/12/1985" , 15 " s e s s o " : "M"

16 . . . 17 }

Listato 3.3: dati anagrafici da codice fiscale