di Pierluigi Paganini*
Alcuni di voi avranno sentito parlare del protocollo OAuth, in molti lo usiamo in maniera inconsapevole, in questo post scopriremo di cosa si tratta e come funziona.
Cos’è il protocollo OAuth
OAuth è un protocollo aperto, sviluppato nel 2006, che definisce i processi di autenticazione per applicazioni desktop e mobile. La sua popolarità è dovuta principalmente alla possibilità di consentire ad applicazioni differenti di interagire scambiando dati in maniera sicura.
OAuth consente ai service provider l’accesso sicuro di terze parti ai dati degli utenti. In pratica, grazie a OAuth un utente può consentire a un altro servizio (detto anche consumer) l’accesso alle sue informazioni archiviate nei sistemi di un particolare service provider, senza tuttavia condividere la sua identità.
Detto in questi termini potrebbe apparire complesso, ma a molti di noi sarà capitato di usare il protocollo OAuth, consentendo a un servizio qualunque di accedere alle nostre informazioni per autenticarsi. Ad esempio, quando LinkedIn ci chiede l’autorizzazione all’uso della lista dei contatti gestita da un altro provider di posta elettronica (come Gmail o Yahoo).
Nel 2012 è stata resa pubblica la verisone OAuth 2.0 dello standard che oggi è implementato nella maggior parte dei framework utilizzati dai principali gruppi di sviluppo con l’intento di offrire ulteriori funzionalità di autenticazione e autorizzazione.
Come funziona OAuth
Gli attori coinvolti in un processo di autenticazione che implementi lo standard OAuth sono:
- un server che fisicamente ospita le informazioni dell’utente (risorsa), detto anche OAuth Provider
- il proprietario della risorsa
- il cliente, detto anche OAuth Consumer, ovvero il soggetto richiedente la risorsa
In uno schema di autenticazione tradizionale client-server, il client fornisce le priorie credenziali al server per accedere alle sue risorse e quindi, ipotizzando che voglia autorizzare un altro servizio a operare in suo conto, è necessario che fornisca le sue username e password. Analizziamo, invece, cosa accade quando si implementa il protocollo OAuth.
Esempio di flusso con protocollo OAuth
Di seguito riportiamo un flusso tipico per l’autorizzazione all’accesso dei contatti da parte di una piattaforma di social networking.
- L’utente si autentica a una piattaforma di social networking come Facebook (nel nostro caso l’applicazione Facebook viene identificata come OAuth Consumer) e decide di importare i propri contatti dal servizio di posta elettronica Gmail (OAuth Provider).
- L’OAuth consumer, quindi Facebook, reindirizza la richiesta all’OAuth Provider per generare un token di richiesta e chiave segreta.
- L’OAuth Provider genera un token di richiesta e la chiave segreta e li invia all’OAuth Consumer.
- L’OAuth Consumer richiede all’utente di autorizzare la richiesta e invia il token di richiesta ricevuto dall’OAuth Provider. Tipicamente è chiesto all’utente di cliccare su di un link o su di un pulsante per fornire l’autorizzazione.
- Fornita l’autorizzazione, ad esempio cliccando su un link, la chiave segreta è inoltrata all’OAuth Provider attraverso le API del protocollo.
- L’OAuth Provider (Gmail) chiede all’utente di autorizzare l’OAuth Consumer (Facebook nel nostro esempio) a utilizzare i propri dati.
- L’utente conferma l’autorizzazione al Consumatore OAuth a utilizzare i propri dati.
- L’OAuth Provider invia all’utente un “token di richiesta” e una “richiesta di token segreto” e reindirizza l’utente all’OAuth Consumer.
- L’utente viene reindirizzato all’OAuth Consumer con un “gettone richiesta” e una “richiesta di token segreto”.
- L’OAuth Consumer presenta il “token di richiesta” e la “richiesta di token segreto” e chiede l’accesso ai contatti degli utenti.
Quanto è sicuro OAuth?
Il protocollo così come sviluppato inizialmente è risultato vulnerabile nella versione OAuth 1.0 ad attacchi di tipo “session fixation” che sostanzialmente si basano sul riutilizzo dei token di autenticazione previsti dal protocollo per l’accesso alle risorse.
La release OAuth 2.0 pone rimedio alle falle della versione precedente ed è quella che oggi viene utilizzata dai principali service provider.
*Pierluigi Paganini
Membro Gruppo di Lavoro Cyber G7 2017 presso Ministero degli Esteri
Membro Gruppo Threat Landscape Stakeholder Group ENISA
Collaboratore SIPAF presso il Mef
