[Security] OAuth: siamo noi ad autorizzare l’accesso ai nostri dati

Cosa accade quando sui social network, come Facebook o Twitter, diamo l’autorizzazione alle applicazioni di accedere ai nostri dati (profilo, info, foto, ecc.)? Semplicemente è come se gli lasciassimo la porta di casa aperta, senza chiuderla a chiave. Infatti, dietro viene utilizzato spesso un protocollo che è chiamato OAuth (open authorization) e di cui descrivo il flusso operativo, senza entrare troppo in dettagli tecnici.

Facebook ha già implementato il protocollo OAuth 2.0 e Twitter, fino a poco tempo fa, usava OAuth 1.0a (definito da RFC 5849). Comunque, il paradigma di autorizzazione è uguale per entrambe le versioni e riguarda lo scambio di informazioni (chiamato spesso “dance“) tra una applicazione client che necessita di accesso ad una risorsa protetta su un server provider e un utente finale (end-user), che ha bisogno di autorizzare l’accesso alle sue risorse protette a tale applicazione client (senza condividere username e password).

OAuth fornisce, dunque, un modo per autorizzare una applicazione ad accedere ai dati che sono stati memorizzati su un servizio online, senza fornire username e password personali. La specifica IETF OAuth 2.0 Protocol descrive il meccanismo di autorizzazione come segue:

  •  l’end-user autorizza l’accesso ad una applicazione (client) ad alcuni dati (scope) gestiti da un servizio web (resource owner)
  • Invece di chiedere le credenziali, il client ridireziona l’end-user verso il resource owner e l’end-user autorizza uno scope direttamente al resource owner: il client identifica se stesso con un client identified univoco e l’end-user lo autorizza;
  • assumendo che l’end-user abbia autorizzato il client, il client notifica e manda un authorization code di conferma all’end-user di avvenuta autorizzazione dello scope; c’è un problema: l’identificatore inviato dal client non è necessariamente segreto, dunque un client malintenzionato potrebbe avere fraudolentemente identificato se stesso e mascherarsi da client autorizzato (trusted publisher);
  • Il client presenta l’authorization code insieme al proprio identificativo e il corrispondente client secret al resource owner e riceve indietro un access token. La combinazione di client identifier, client secret e authorization code assicura che quel resource owner possa positivamente identificare il cliente e autorizzarlo. Questo access token può opzionalmente avere vita breve ed essere refreshato dal client.
  • il client usa l’access token per fare richieste fino a quando l’access token non viene revocato (dall’end-user) o scade.

OAuth permette, dunque, anche di revocare da parte di un end-user l’autorizzazione al client.

Vi segnalo di seguito due link da cui si evince che la versione OAuth 1.0 presenta grosse limitazioni e debolezze (in termini di sicurezza), specie per le applicazioni desktop e mobile:

La versione OAUTH 1.0a è stata definita così:

“OAuth 1.0a is an inelegant hack that lacks maturity and fails to provide clear guidance on many critical issues that are essential to building a robust authentication system.”

 

Facebook, Twitter e Google hanno differenti varianti dello standard e interagiscono diversamente con applicazioni di terze parti. Con OAUTH 2.0 le cose sono cambiate e migliorate.

Ecco quali sono stati i principali svantaggi e problemi dovuti all’utilizzo di OAUTH 1.0: le consumer key non erano così segrete: le applicazioni che comunicano con i servizi OAUTH-enabled possono usare un set di chiavi – dette consumer key e consumer secret – per identificare univocamente se stessi verso il servizio. Ciò permette al servizio OAUTH-enabled di dire all’utente che una applicazione di terze parti vuole accedere al loro account durante il processo di autorizzazione. Questo funziona relativamente bene per l’autenticazione server-to-server, ma non per le applicazioni desktop o mobile che sono distribuite presso gli end-users, visto che non viene più garantita la segretezza della consumer secret key. Se la chiave viene inserita (embedded) nell’applicazione stessa, è possibile per un client malintenzionato estrarre tale chiave e usarla per mascherarsi e accedere al servizio.

Sul sito di Facebook, nella sezione per gli sviluppatori, si legge questo:

A quali dati posso accedere con il protocollo OAuth 2.0?

Gli sviluppatori possono usare il protocollo OAuth 2.0 in vari flussi di lavoro per l’autenticazione e l’autorizzazione degli utenti. Questo metodo offre agli sviluppatori tutte le informazioni pubbliche presenti sul profilo (diario) dell’utente, oltre alle informazioni private per le quali è stata concessa un’autorizzazione estesa. Gli sviluppatori possono anche accedere a tutte le informazioni condivise come pubbliche, quali il nome utente e la foto. Per ulteriori informazioni sull’autenticazione, clicca qui.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

AlphaOmega Captcha Classica  –  Enter Security Code
     
 


− 1 = otto