[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.

Continua la lettura