OAuth: uti­liz­za­re i dati su più piat­ta­for­me

Al giorno d'oggi uti­liz­zia­mo numerosi siti web, programmi e ap­pli­ca­zio­ni mobile per rendere la nostra vita personale e pro­fes­sio­na­le più facile o con­for­te­vo­le. Con una tale varietà di strumenti, è diventato normale per molti uti­liz­za­re i contenuti di un'ap­pli­ca­zio­ne di un sito web (come Instagram) su un altro sito web (come Facebook); in altre parole, operare su più piat­ta­for­me. Tuttavia, poiché durante questi processi viene tra­sfe­ri­to un gran numero di dati personali, la questione sicurezza della propria privacy diventa centrale. Il pro­to­col­lo di au­to­riz­za­zio­ne OAuth è stato pro­get­ta­to per ridurre il rischio di un uso improprio di dati non au­to­riz­za­to. Ma riesce a sod­di­sfa­re le aspet­ta­ti­ve?

OAuth, ab­bre­via­zio­ne di "Open Au­tho­ri­za­tion", è un pro­to­col­lo standard aperto che consente una au­to­riz­za­zio­ne API sicura. Il termine tecnico di pro­gram­ma­zio­ne API (ab­bre­via­zio­ne di "Ap­pli­ca­tion Pro­gram­ming Interface") si riferisce in questo contesto ad una in­ter­fac­cia che funge da tra­smet­ti­to­re di dati tra diverse ap­pli­ca­zio­ni, in­ter­fac­ce utente o pagine web. L'au­to­riz­za­zio­ne dei tra­sfe­ri­men­ti di dati ef­fet­tua­ti per mezzo delle API è ne­ces­sa­ria in quanto al­tri­men­ti sussiste il rischio che terzi non au­to­riz­za­ti possano in­ter­cet­ta­re i dati e uti­liz­zar­li il­le­git­ti­ma­men­te per scopi personali.

Questo significa, ad esempio, che se un'ap­pli­ca­zio­ne deve pub­bli­ca­re per conto di un utente un post su Facebook (e quindi accedere all'API di Facebook), l’utente deve fornirle l’au­to­riz­za­zio­ne ne­ces­sa­ria. Allo stesso modo, un'ap­pli­ca­zio­ne ha bisogno del permesso del­l'u­ten­te per estra­po­la­re in­for­ma­zio­ni sul suo profilo da un altro servizio. Tramite il pro­to­col­lo OAuth, l'utente può concedere tale delega (au­to­riz­za­zio­ne) senza dover fornire al­l'ap­pli­ca­zio­ne au­to­riz­za­ta username e password, man­te­nen­do quindi il pieno controllo sui propri dati.

Viceversa, fornitori come Google, Twitter e Facebook uti­liz­za­no OAuth per rendere i loro prodotti e servizi più fles­si­bi­li e allo stesso tempo più sicuri, ad esempio at­tra­ver­so soluzioni Single sign-on. Anche Amazon e Microsoft figurano tra le grandi aziende che uti­liz­za­no OAuth come standard di delega di accesso per i loro servizi.

La versione non retro com­pa­ti­bi­le di OAuth2 (chiamata anche "OAuth 2.0") è stata pub­bli­ca­ta nel­l'ot­to­bre 2012 come revisione completa di OAuth e at­tual­men­te lo ha in gran parte rim­piaz­za­to. L’API Graph di Facebook supporta come standard di au­to­riz­za­zio­ne uni­ca­men­te la versione ag­gior­na­ta del pro­to­col­lo, che si basa sul livello di au­ten­ti­ca­zio­ne OpenID Connect (OIDC).

In linea di principio, il compito di OAuth2 è lo stesso del suo pre­de­ces­so­re: con­sen­ti­re al­l'u­ten­te, tramite l'au­to­riz­za­zio­ne API, una maggiore fles­si­bi­li­tà man­te­nen­do al contempo un alto livello di sicurezza. Sono state inoltre superate molte delle carenze del pro­to­col­lo originale, che rendevano la codifica e l'im­ple­men­ta­zio­ne più difficili mano a mano che i sistemi di Facebook, Twitter e altri operatori API di­ven­ta­va­no sempre più complessi.

Al di là di una ter­mi­no­lo­gia com­ple­ta­men­te dif­fe­ren­te, la grande novità di OAuth2 è che, di­ver­sa­men­te dal suo pre­de­ces­so­re, non richiede più firme crit­to­gra­fi­che nei processi di co­mu­ni­ca­zio­ne Machine to Machine (M2), previsti dal pro­to­col­lo. Ciò facilita no­te­vol­men­te l'ap­pli­ca­zio­ne e l'e­sten­sio­ne del pro­to­col­lo, ma significa anche che questo è tec­ni­ca­men­te meno sicuro. Un aspetto per il quale OAuth2 è stato oggetto di alcune critiche.

Open Au­tho­ri­za­tion 2.0 è stato inoltre integrato con processi di au­to­riz­za­zio­ne mag­gior­men­te dif­fe­ren­zia­ti (Grant Types) e per­fe­zio­na­to nelle pre­sta­zio­ni. Gli svi­lup­pa­to­ri sono riusciti a fare in modo che OAuth2 non chieda più ad ogni fase di co­mu­ni­ca­zio­ne i dati di accesso del­l'u­ten­te (Resource Owner), ma solo alla prima au­to­riz­za­zio­ne della ri­spet­ti­va ap­pli­ca­zio­ne (client). Un'altra in­no­va­zio­ne degna di nota riguarda i token di accesso con scadenza più breve, che sem­pli­fi­ca­no al servizio (Resource Server) il processo di an­nul­la­men­to delle au­to­riz­za­zio­ni concesse. Inoltre, l'utente può decidere au­to­no­ma­men­te quali au­to­riz­za­zio­ni (scope) concedere a un'ap­pli­ca­zio­ne.

So­prat­tut­to per quanto riguarda il Single sign-on (SSO), OAuth è im­por­tan­te quanto OpenID e SAML. Ma anche se tutti questi metodi ri­guar­da­no la verifica af­fi­da­bi­le dei dati iden­ti­fi­ca­ti­vi degli utenti, pre­sen­ta­no tuttavia delle dif­fe­ren­ze so­stan­zia­li.

OpenID (ab­bre­via­zio­ne di "Open Iden­ti­fi­ca­tion") è un pro­to­col­lo aperto: quando un utente crea un account OpenID può uti­liz­za­re questo pro­to­col­lo per accedere via token ad altri servizi e ap­pli­ca­zio­ni che lo sup­por­ta­no. Un buon esempio in merito è il pulsante "Accedi con Google" che ormai troviamo su molti siti web e che consente una procedura Single sign-on tramite l'account Google del­l'u­ten­te.

Quindi OpenID, a dif­fe­ren­za di OAuth, non è uno standard di au­to­riz­za­zio­ne in senso stretto, ma uno standard di au­ten­ti­ca­zio­ne. Tuttavia, i due pro­to­col­li sono stret­ta­men­te legati fin dal 2014: su OAuth 2.0 si basa la nuova versione di OpenID, chiamata OpenID Connect (OIDC). OAuth2 consente a diversi tipi di ap­pli­ca­zio­ni (client) di ve­ri­fi­ca­re l'i­den­ti­tà del­l'u­ten­te at­tra­ver­so l'au­ten­ti­ca­zio­ne per mezzo di un server di au­to­riz­za­zio­ne e oltre a ciò di ottenere ulteriori in­for­ma­zio­ni di base sul­l'u­ten­te. In cambio, il pro­to­col­lo viene com­ple­ta­to con tutte le funzioni ne­ces­sa­rie per il login e il Single sign-on. OpenID Connect può anche essere esteso a funzioni opzionali come, ad esempio, la gestione delle sessioni e la crit­to­gra­fia dei dati iden­ti­fi­ca­ti­vi.

Questo standard aperto e basato su XML "Security Assertion Markup Language" (in breve: SAML) combina per così dire le proprietà dei due metodi pre­ce­den­ti: infatti è sia uno standard di au­ten­ti­ca­zio­ne che di au­to­riz­za­zio­ne. Dal punto di vista del fun­zio­na­men­to, SAML è simile a OpenID e viene uti­liz­za­to anche per la procedura Single sign-on.

Una pa­no­ra­mi­ca dei ruoli e dei processi di au­to­riz­za­zio­ne definiti nel pro­to­col­lo OAuth2 consente di com­pren­der­ne il fun­zio­na­men­to.

Nel pro­to­col­lo OAuth2 si di­stin­guo­no quattro ruoli:

• Resource Owner (anche: user, utente): entità che concede al client l’accesso a dati personali protetti (anche: risorse).
• Resource Server (anche: servizio): server in cui vengono salvati i dati protetti di un Resource Owner.
• Client (anche: terza parte, third-party): ap­pli­ca­zio­ne desktop, web o mobile che chiede l’accesso ai dati protetti del Resource Owner.
• Server di au­to­riz­za­zio­ne: server che autentica il Resource Owner e rilascia un token di accesso tem­po­ra­neo ad un ambito di ap­pli­ca­zio­ne (scope) definito dallo stesso utente. Nella realtà il server di au­to­riz­za­zio­ne e il Resource Server vengono spesso gestiti insieme e in questo caso si parla di OAuth Server.

Viene inoltre operata una di­stin­zio­ne tra quattro processi di au­to­riz­za­zio­ne pre­de­fi­ni­ti (Grant Types), uti­liz­za­ti in ap­pli­ca­zio­ni dif­fe­ren­ti:

• Codice di au­to­riz­za­zio­ne (Au­tho­ri­za­tion Code): il client chiede al Resource Owner di accedere al server di au­to­riz­za­zio­ne. Il Resource Owner viene quindi rein­di­riz­za­to al client con un codice di au­to­riz­za­zio­ne. In cambio di questo codice, il server di au­to­riz­za­zio­ne rilascia un token di accesso per il client.
• Au­to­riz­za­zio­ne implicita (Implicit Au­tho­ri­za­tion): questo processo di au­to­riz­za­zio­ne è molto simile al processo di au­to­riz­za­zio­ne pre­ce­den­te, ma è meno complesso in quanto il server di au­to­riz­za­zio­ne rilascia di­ret­ta­men­te il token di accesso.
• Rilascio della password da parte del Resource Owner (Resource Owner Password Cre­den­tials): in questo caso il Resource Owner affida i suoi dati di accesso di­ret­ta­men­te al client. Questo punto è in contrasto con il principio su cui si basa OAuth, ma risulta comunque meno oneroso per il Resource Owner.
• Cre­den­zia­li del client (Client Cre­den­tials): questo processo di au­to­riz­za­zio­ne par­ti­co­lar­men­te semplice viene uti­liz­za­to quando il client vuole accedere a dati che non hanno un pro­prie­ta­rio o non ne­ces­si­ta­no di au­to­riz­za­zio­ne.

Se il client in futuro ha bisogno di accedere nuo­va­men­te ai dati protetti del Resource Owner, può uti­liz­za­re un refresh-token tem­po­ra­neo, ma con una scadenza più lunga, per ri­chie­de­re un nuovo token di accesso al server di au­to­riz­za­zio­ne. Non viene richiesta in questo caso un’ulteriore au­to­riz­za­zio­ne da parte del Resource Owner.

I social network Pinterest e Facebook for­ni­sco­no esempi concreti delle fasi di OAuth2. Pinterest offre la pos­si­bi­li­tà di importare i contatti dalle liste di amici di Facebook. Per fare questo ha bisogno di accedere al ri­spet­ti­vo account e ai dati in esso me­mo­riz­za­ti. Per motivi di sicurezza dati, tuttavia, non sarebbe con­si­glia­bi­le tra­smet­te­re il nome utente e la password di Facebook perché in questo modo Pinterest avrebbe un accesso il­li­mi­ta­to a tutti i dati e funzioni del­l'ac­count Facebook in qualsiasi momento. Affinché Pinterest possa accedere ai dati di Facebook viene dunque uti­liz­za­to OAuth2:

1. Per prima cosa accedete al vostro account Pinterest e andate nelle im­po­sta­zio­ni del profilo utente.
2. Nella barra del menu "Social network" spuntate la voce “Sì” accanto a "Facebook".
3. Pinterest chiede ora di accedere a Facebook e con­fer­ma­re l'ap­pli­ca­zio­ne Pinterest. Questa azione è con­si­de­ra­ta un permesso di au­to­riz­za­zio­ne.
4. Pinterest richiede un token di accesso al server di au­to­riz­za­zio­ne di Facebook e lo utilizza per accedere ai dati protetti sul Resource Server.
5. Gli amici di Facebook importati sono ora presenti nel­l'ac­count di Pinterest.

Il fatto che anche un sistema per la pro­te­zio­ne dei dati personali come OAuth non possa essere perfetto al 100% è stato già di­mo­stra­to nel­l'a­pri­le 2009, quando è stata rilevata una falla nella sicurezza durante il processo di au­ten­ti­ca­zio­ne del pro­to­col­lo. Come per molti altri sistemi di questo tipo, il phishing rap­pre­sen­ta un pericolo costante: tra aprile e maggio 2017, un milione di utenti di Gmail sono stati vittime di un attacco di phishing basato su OAuth. In una e-mail frau­do­len­ta, è stato chiesto loro di au­to­riz­za­re una in­ter­fac­cia fittizia per con­sen­ti­re a una presunta ap­pli­ca­zio­ne chiamata "Google App" di accedere alle in­for­ma­zio­ni sul loro account.

Lo sviluppo della versione suc­ces­si­va OAuth2 dovrebbe, quindi, non soltanto fa­ci­li­ta­re l'im­ple­men­ta­zio­ne del pro­to­col­lo, sempre più complesso, ma anche au­men­tar­ne la sicurezza. Nel­l'ot­to­bre 2012, venne raggiunto un risultato de­fi­ni­ti­vo, senza però l'ap­pro­va­zio­ne di quegli svi­lup­pa­to­ri che erano stati coinvolti nella versione originale. Solo Eran Hammer-Lahav, a capo di OAuth2, aveva lavorato alla versione pre­ce­den­te e anche lui abbandonò il nuovo progetto tre mesi prima della sua uscita. In un articolo del suo blog hue­ni­ver­se.com del 26 luglio 2012 spiegò i motivi della sua decisione e definì OAuth 2.0 una “via per l’inferno”.

Cos’era successo? Secondo Hammer-Lahav, lo sviluppo del nuovo pro­to­col­lo era stato de­ter­mi­na­to da dibattiti continui tra gli svi­lup­pa­to­ri e le aziende coinvolte (tra cui Yahoo!, Google, Twitter e anche la Deutsche Bank). Da un certo momento in poi i punti con­tro­ver­si sono stati ignorati a favore degli interessi com­mer­cia­li. La con­se­guen­za fu, a suo avviso, un pro­to­col­lo che non poteva più essere descritto come tale perché invece di rap­pre­sen­ta­re uno standard in senso stretto, era diventato piuttosto un framework che poteva essere adattato ed esteso a pia­ci­men­to. OAuth2 avrebbe così perso la ca­rat­te­ri­sti­ca del­l'in­te­ro­pe­ra­bi­li­tà, in quanto le sue diverse im­ple­men­ta­zio­ni non sarebbero state più ne­ces­sa­ria­men­te com­pa­ti­bi­li tra loro.

Un altro aspetto che Hammer-Lahav rimpiange è il fatto che sono state prese decisioni per un’im­ple­men­ta­zio­ne più semplice (ad esempio eli­mi­nan­do le firme) e questo ha portato ad una mancanza di sicurezza. Per pro­gram­ma­re un'ap­pli­ca­zio­ne sicura che supporti OAuth2, gli svi­lup­pa­to­ri devono avere una notevole espe­rien­za. È quindi più probabile che in futuro si ac­cu­mu­le­ran­no sempre di più in rete ap­pli­ca­zio­ni non sicure con errori d’im­ple­men­ta­zio­ne ine­vi­ta­bi­li, secondo Hammer-Lahav, date le spe­ci­fi­che in­com­ple­te ed ec­ces­si­va­men­te complesse.

Hammer-Lahav non aveva tutti i torti: nel 2016 un gruppo di ricerca del­l'U­ni­ver­si­tà di Treviri si è occupato per la prima volta della sicurezza di OAuth2 e ha in­di­vi­dua­to due falle nella sicurezza. Una di queste ha reso possibile degli attacchi man in the middle. In generale i ri­cer­ca­to­ri ritengono che il pro­to­col­lo sia re­la­ti­va­men­te sicuro, a con­di­zio­ne che venga attuato cor­ret­ta­men­te. Secondo i dati forniti dal team di OAuth2, le carenze sono state già superate. Tuttavia, il rapporto di questa ricerca è stata l'oc­ca­sio­ne per molti esperti IT per esaminare più da vicino l’utilizzo sicuro di OAuth 2.0.