OAuth è un protocollo di autorizzazione aperto e standard, progettato specificamente per lavorare con l'Hypertext Transfer Protocol (HTTP). Essenzialmente consente l'emissione di un token di accesso da parte di un server autorizzativo ad un client di terze parti, previa approvazione dell'utente proprietario della risorsa cui si intende accedere.[1]
Questo meccanismo, detto di "access delegation" (delega di accesso), è utilizzato da compagnie quali: Amazon, Google, Facebook, Microsoft, Twitter, Dropbox per consentire all'utente di condividere informazioni circa il proprio account con altre applicazioni o siti web. È comunemente utilizzato come modalità per gli utenti in Internet per garantire alle applicazioni ed ai siti web l'accesso alle proprie informazioni senza fornire loro alcuna password.
Tale protocollo permette l'autorizzazione di API di sicurezza con un metodo standard e semplice in varie situazioni: applicazioni "mobile", applicazioni "web", applicazioni per personal computer.
OAuth logo
Per gli sviluppatori di applicazioni è un metodo per pubblicare e interagire con dati protetti. OAuth garantisce ai service provider l'accesso da parte di terzi ai dati degli utenti proteggendo contemporaneamente le loro credenziali. Per esempio permette all'utente di dare ad un sito, chiamato consumer, l'accesso alle informazioni presenti su un altro sito, detto service provider, senza condividere la propria identità.
Storia e versioni
Sviluppato da Blaine Cook e Chris Messina a partire dal novembre 2006.
Il protocollo OAuth 1.0 è stato pubblicato come RFC 5849 nell'aprile 2010.
Un'evoluzione di OAuth 1.0, è OAuth 2.0 che viene descritta nel documento RFC 6749 dell'ottobre 2012.
Attori
In OAuth vi sono i seguenti attori principali:
l'Utente o Resource Owner
il Client o Consumer
il Resource Server o Service Provider
l'Authorization Server
Il Resource Owner è la persona che può dare l'accesso ad una qualche porzione del proprio account. È la persona che può garantire l'accesso alle risorse protette presenti sul "Resource Server".
Il Client è l'applicazione che cerca di ottenere l'accesso all'account dell'utente e che richiede il permesso dell' "Utente" prima di poter accedere alle risorse protette.
Il Resource Server è il server utilizzato per accedere alle risorse protette dell'utente.
L'Authorization Server è il server che presenta l'interfaccia dove l'Utente approva o nega la richiesta di accesso. In piccoli ambienti può coincidere con il Resource Server.
Il Client interagisce con il Resource Server per ottenere delle credenziali temporanee. Per accedere alle risorse protette, il Client richiede all'Utente il permesso, detto token di accesso. Una volta ottenuto il token di accesso può accedere e interagire con le risorse stabilite per un breve periodo.
OAuth 1.0
Motivazioni
L'idea di base è quella di autorizzare terze parti a gestire documenti privati senza condividere la password. La condivisione della password infatti presenta molti limiti a livello di sicurezza, come per esempio non garantisce supporto per singoli privilegi su determinati file o operazioni, e soprattutto rende accessibile l'intero account e il pannello di amministrazione. In particolare questo accesso incondizionato è indesiderato. Inoltre l'unico modo per revocare l'accesso è cambiare la password dell'intero account.
OAuth è nato quindi con il presupposto di garantire l'accesso delegato ad un client specifico per determinate risorse sul server per un tempo limitato, con possibilità di revoca.
Sicurezza e limiti
OAuth 1.0 presenta alcune limitazioni a livello di sicurezza. Il server non svolge questo servizio "gratuitamente", ma raccoglie informazioni riguardanti l'utente, il client e la loro interazione. OAuth 1.0 non garantisce confidenzialità né sulle richieste né sui contenuti. Sebbene questo protocollo garantisca che il client non acceda ad informazioni indesiderate, non garantisce che l'uso delle risorse autorizzate rimanga nell'ambito specificato. Per questo motivo OAuth suggerisce al server di proteggere le risorse tramite il protocollo TLS.
Per garantire l'integrità delle informazioni, OAuth offre 3 metodi diversi:
Un ulteriore problema noto è quello del phishing. Il client potrebbe indirizzare l'utente a una pagina di accesso fasulla del server per richiedere l'autenticazione e ottenere le credenziali dell'utente.
OAuth 2.0
Un'evoluzione di OAuth 1.0 è descritta nel documento RFC 6749 dell'ottobre 2012. Il principio di funzionamento è il medesimo, ma differisce dal predecessore per qualche miglioramento nel servizio. Infatti OAuth 2.0 presenta una chiara divisione dei ruoli, implementando un mediatore tra client e server. Un altro vantaggio rispetto alla precedente versione è dato dalla possibilità di prolungare il tempo di utilizzo del token di accesso qualora desiderato.
Gli attori sono i medesimi con l'aggiunta di un server mediatore. Quest'ultimo ha il principale compito di gestire i token di accesso tra client e server. Il server che funge da mediatore può essere lo stesso che ospita le risorse alle quali accedere. Il server mediatore può gestire token di accesso provenienti da più di un solo server.
I limiti di OAuth 2.0 sono i medesimi di OAuth 1.0. Questi due protocolli Oauth non sono compatibili fra loro.
Sicurezza
Nell'Aprile-Maggio 2017, circa un milione di utenti di "Gmail" (meno dello 0.1% degli utenti di Maggio 2017) sono stati oggetto di un attacco di phishing basato su OAuth. Questi utenti hanno ricevuto una e-mail che fingeva di provenire da un collega, impiegato o amico che voleva condividere un documento su "Google Docs"[2]. A coloro che hanno cliccato sul link fornito nell'e-mail è stato chiesto di collegarsi e di consentire ad un programma potenzialmente malevolo di terze parti, chiamato "Google Apps" di accedere ai propri account di email, contatti e documenti online. L'attacco di phishing è stato bloccato da "Google" approssimativamente in un'ora avvisando coloro che avevano dato accesso alla propria email a "Google Apps" di revocare l'accesso e di cambiare la propria password.
