OAuth: utilizzare i dati su più piattaforme

Al giorno d'oggi utilizziamo numerosi siti web, programmi e applicazioni mobile per rendere la nostra vita personale e professionale più facile o confortevole. Con una tale varietà di strumenti, è diventato normale per molti utilizzare i contenuti di un'applicazione di un sito web (come Instagram) su un altro sito web (come Facebook); in altre parole, operare su più piattaforme. Tuttavia, poiché durante questi processi viene trasferito un gran numero di dati personali, la questione sicurezza della propria privacy diventa centrale. Il protocollo di autorizzazione OAuth è stato progettato per ridurre il rischio di un uso improprio di dati non autorizzato. Ma riesce a soddisfare le aspettative?

OAuth, abbreviazione di "Open Authorization", è un protocollo standard aperto che consente una autorizzazione API sicura. Il termine tecnico di programmazione API (abbreviazione di "Application Programming Interface") si riferisce in questo contesto ad una interfaccia che funge da trasmettitore di dati tra diverse applicazioni, interfacce utente o pagine web. L'autorizzazione dei trasferimenti di dati effettuati per mezzo delle API è necessaria in quanto altrimenti sussiste il rischio che terzi non autorizzati possano intercettare i dati e utilizzarli illegittimamente per scopi personali.

Questo significa, ad esempio, che se un'applicazione deve pubblicare per conto di un utente un post su Facebook (e quindi accedere all'API di Facebook), l’utente deve fornirle l’autorizzazione necessaria. Allo stesso modo, un'applicazione ha bisogno del permesso dell'utente per estrapolare informazioni sul suo profilo da un altro servizio. Tramite il protocollo OAuth, l'utente può concedere tale delega (autorizzazione) senza dover fornire all'applicazione autorizzata username e password, mantenendo quindi il pieno controllo sui propri dati.

Viceversa, fornitori come Google, Twitter e Facebook utilizzano OAuth per rendere i loro prodotti e servizi più flessibili e allo stesso tempo più sicuri, ad esempio attraverso soluzioni Single sign-on. Anche Amazon e Microsoft figurano tra le grandi aziende che utilizzano OAuth come standard di delega di accesso per i loro servizi.

La versione non retro compatibile di OAuth2 (chiamata anche "OAuth 2.0") è stata pubblicata nell'ottobre 2012 come revisione completa di OAuth e attualmente lo ha in gran parte rimpiazzato. L’API Graph di Facebook supporta come standard di autorizzazione unicamente la versione aggiornata del protocollo, che si basa sul livello di autenticazione OpenID Connect (OIDC).

In linea di principio, il compito di OAuth2 è lo stesso del suo predecessore: consentire all'utente, tramite l'autorizzazione API, una maggiore flessibilità mantenendo al contempo un alto livello di sicurezza. Sono state inoltre superate molte delle carenze del protocollo originale, che rendevano la codifica e l'implementazione più difficili mano a mano che i sistemi di Facebook, Twitter e altri operatori API diventavano sempre più complessi.

Al di là di una terminologia completamente differente, la grande novità di OAuth2 è che, diversamente dal suo predecessore, non richiede più firme crittografiche nei processi di comunicazione Machine to Machine (M2), previsti dal protocollo. Ciò facilita notevolmente l'applicazione e l'estensione del protocollo, ma significa anche che questo è tecnicamente meno sicuro. Un aspetto per il quale OAuth2 è stato oggetto di alcune critiche.

Open Authorization 2.0 è stato inoltre integrato con processi di autorizzazione maggiormente differenziati (Grant Types) e perfezionato nelle prestazioni. Gli sviluppatori sono riusciti a fare in modo che OAuth2 non chieda più ad ogni fase di comunicazione i dati di accesso dell'utente (Resource Owner), ma solo alla prima autorizzazione della rispettiva applicazione (client). Un'altra innovazione degna di nota riguarda i token di accesso con scadenza più breve, che semplificano al servizio (Resource Server) il processo di annullamento delle autorizzazioni concesse. Inoltre, l'utente può decidere autonomamente quali autorizzazioni (scope) concedere a un'applicazione.

Soprattutto per quanto riguarda il Single sign-on (SSO), OAuth è importante quanto OpenID e SAML. Ma anche se tutti questi metodi riguardano la verifica affidabile dei dati identificativi degli utenti, presentano tuttavia delle differenze sostanziali.

OpenID (abbreviazione di "Open Identification") è un protocollo aperto: quando un utente crea un account OpenID può utilizzare questo protocollo per accedere via token ad altri servizi e applicazioni che lo supportano. 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 dell'utente.

Quindi OpenID, a differenza di OAuth, non è uno standard di autorizzazione in senso stretto, ma uno standard di autenticazione. Tuttavia, i due protocolli sono strettamente 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 applicazioni (client) di verificare l'identità dell'utente attraverso l'autenticazione per mezzo di un server di autorizzazione e oltre a ciò di ottenere ulteriori informazioni di base sull'utente. In cambio, il protocollo viene completato con tutte le funzioni necessarie 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 crittografia dei dati identificativi.

Questo standard aperto e basato su XML "Security Assertion Markup Language" (in breve: SAML) combina per così dire le proprietà dei due metodi precedenti: infatti è sia uno standard di autenticazione che di autorizzazione. Dal punto di vista del funzionamento, SAML è simile a OpenID e viene utilizzato anche per la procedura Single sign-on.

Una panoramica dei ruoli e dei processi di autorizzazione definiti nel protocollo OAuth2 consente di comprenderne il funzionamento.

Nel protocollo OAuth2 si distinguono 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): applicazione desktop, web o mobile che chiede l’accesso ai dati protetti del Resource Owner.
• Server di autorizzazione: server che autentica il Resource Owner e rilascia un token di accesso temporaneo ad un ambito di applicazione (scope) definito dallo stesso utente. Nella realtà il server di autorizzazione e il Resource Server vengono spesso gestiti insieme e in questo caso si parla di OAuth Server.

Viene inoltre operata una distinzione tra quattro processi di autorizzazione predefiniti (Grant Types), utilizzati in applicazioni differenti:

• Codice di autorizzazione (Authorization Code): il client chiede al Resource Owner di accedere al server di autorizzazione. Il Resource Owner viene quindi reindirizzato al client con un codice di autorizzazione. In cambio di questo codice, il server di autorizzazione rilascia un token di accesso per il client.
• Autorizzazione implicita (Implicit Authorization): questo processo di autorizzazione è molto simile al processo di autorizzazione precedente, ma è meno complesso in quanto il server di autorizzazione rilascia direttamente il token di accesso.
• Rilascio della password da parte del Resource Owner (Resource Owner Password Credentials): in questo caso il Resource Owner affida i suoi dati di accesso direttamente al client. Questo punto è in contrasto con il principio su cui si basa OAuth, ma risulta comunque meno oneroso per il Resource Owner.
• Credenziali del client (Client Credentials): questo processo di autorizzazione particolarmente semplice viene utilizzato quando il client vuole accedere a dati che non hanno un proprietario o non necessitano di autorizzazione.

Se il client in futuro ha bisogno di accedere nuovamente ai dati protetti del Resource Owner, può utilizzare un refresh-token temporaneo, ma con una scadenza più lunga, per richiedere un nuovo token di accesso al server di autorizzazione. Non viene richiesta in questo caso un’ulteriore autorizzazione da parte del Resource Owner.

I social network Pinterest e Facebook forniscono esempi concreti delle fasi di OAuth2. Pinterest offre la possibilità di importare i contatti dalle liste di amici di Facebook. Per fare questo ha bisogno di accedere al rispettivo account e ai dati in esso memorizzati. Per motivi di sicurezza dati, tuttavia, non sarebbe consigliabile trasmettere il nome utente e la password di Facebook perché in questo modo Pinterest avrebbe un accesso illimitato a tutti i dati e funzioni dell'account Facebook in qualsiasi momento. Affinché Pinterest possa accedere ai dati di Facebook viene dunque utilizzato OAuth2:

1. Per prima cosa accedete al vostro account Pinterest e andate nelle impostazioni 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 confermare l'applicazione Pinterest. Questa azione è considerata un permesso di autorizzazione.
4. Pinterest richiede un token di accesso al server di autorizzazione di Facebook e lo utilizza per accedere ai dati protetti sul Resource Server.
5. Gli amici di Facebook importati sono ora presenti nell'account di Pinterest.

Il fatto che anche un sistema per la protezione dei dati personali come OAuth non possa essere perfetto al 100% è stato già dimostrato nell'aprile 2009, quando è stata rilevata una falla nella sicurezza durante il processo di autenticazione del protocollo. Come per molti altri sistemi di questo tipo, il phishing rappresenta 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 fraudolenta, è stato chiesto loro di autorizzare una interfaccia fittizia per consentire a una presunta applicazione chiamata "Google App" di accedere alle informazioni sul loro account.

Lo sviluppo della versione successiva OAuth2 dovrebbe, quindi, non soltanto facilitare l'implementazione del protocollo, sempre più complesso, ma anche aumentarne la sicurezza. Nell'ottobre 2012, venne raggiunto un risultato definitivo, senza però l'approvazione di quegli sviluppatori che erano stati coinvolti nella versione originale. Solo Eran Hammer-Lahav, a capo di OAuth2, aveva lavorato alla versione precedente e anche lui abbandonò il nuovo progetto tre mesi prima della sua uscita. In un articolo del suo blog hueniverse.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 protocollo era stato determinato da dibattiti continui tra gli sviluppatori e le aziende coinvolte (tra cui Yahoo!, Google, Twitter e anche la Deutsche Bank). Da un certo momento in poi i punti controversi sono stati ignorati a favore degli interessi commerciali. La conseguenza fu, a suo avviso, un protocollo che non poteva più essere descritto come tale perché invece di rappresentare uno standard in senso stretto, era diventato piuttosto un framework che poteva essere adattato ed esteso a piacimento. OAuth2 avrebbe così perso la caratteristica dell'interoperabilità, in quanto le sue diverse implementazioni non sarebbero state più necessariamente compatibili tra loro.

Un altro aspetto che Hammer-Lahav rimpiange è il fatto che sono state prese decisioni per un’implementazione più semplice (ad esempio eliminando le firme) e questo ha portato ad una mancanza di sicurezza. Per programmare un'applicazione sicura che supporti OAuth2, gli sviluppatori devono avere una notevole esperienza. È quindi più probabile che in futuro si accumuleranno sempre di più in rete applicazioni non sicure con errori d’implementazione inevitabili, secondo Hammer-Lahav, date le specifiche incomplete ed eccessivamente complesse.

Hammer-Lahav non aveva tutti i torti: nel 2016 un gruppo di ricerca dell'Università di Treviri si è occupato per la prima volta della sicurezza di OAuth2 e ha individuato due falle nella sicurezza. Una di queste ha reso possibile degli attacchi man in the middle. In generale i ricercatori ritengono che il protocollo sia relativamente sicuro, a condizione che venga attuato correttamente. Secondo i dati forniti dal team di OAuth2, le carenze sono state già superate. Tuttavia, il rapporto di questa ricerca è stata l'occasione per molti esperti IT per esaminare più da vicino l’utilizzo sicuro di OAuth 2.0.