Social login: autenticazione tramite social network
È ormai uso comune usufruire di un servizio offerto da una piattaforma, attraverso la creazione di un account che permette non solo di autenticarci tramite le credenziali scelte (nome utente/email e password) ma anche di fornire informazioni personali come data di nascita, interessi e molto altro. Tale procedura è spesso lunga e tediosa e può scoraggiare l’utente finale dall’usufruire del servizio.
Negli ultimi anni, tuttavia, il processo di creazione di un nuovo account è stato semplificato e reso più rapido. In particolare, è ora possibile accedere a un servizio offerto da un’applicazione di terze parti attraverso il proprio account social, permettendo al gestore in questione di ottenere le informazioni basilari dell’utente, e all’utente stesso di accedere rapidamente al servizio. Questo approccio prende il nome di social login ed è una forma di single sign-on (SSO) che serve a effettuare l’autenticazione a una piattaforma di terze parti attraverso informazioni già esistenti, memorizzate da un servizio di social networking, come ad esempio Facebook, Google o Twitter. Attraverso questo approccio, i dettagli relativi all’utente vengono forniti dalla piattaforma social scelta per il login e, se utilizzati in modo corretto, migliorano l’esperienza dell’utente, che visualizzerà contenuti più affini alla sua personalità. Ovviamente, sono molteplici i servizi che offrono comunque la possibilità di registrarsi attraverso un sistema più tradizionale, permettendo a coloro che non dispongono di un account social di non essere esclusi.
Il social login può essere implementato come un sistema basato su un protocollo di autenticazione decentralizzato (ossia senza un server che mantenga le informazioni scambiate attraverso il protocollo), come OpenID, per limitare alla sola autenticazione lo scambio di dati con il social network. In alternativa, può essere impiegato Open Authorization (OAuth) che fornisce un protocollo di autorizzazione sicuro da utilizzare in combinazione con i sistemi di autenticazione forniti dalle piattaforme social.
Attraverso OAuth, la piattaforma che eroga il servizio ottiene dal social network di destinazione un access token, con il quale verrà identificata. Può inoltre richiedere l’accesso alle informazioni sulle autorizzazioni dell’utente, ossia le informazioni alle quali le aziende accedono perché l’utente ha acconsentito all’utilizzo di quei dati.
Sia OpenID che OAuth sono protocolli validi, decentralizzati e basati su standard aperti, che garantiscono la sicurezza, l’identificazione dell’utente tramite autenticazione e l’autorizzazione del processo. Ciononostante, la semplicità di implementazione di OAuth per gli sviluppatori e per le piattaforme social ha fatto sì che, negli ultimi anni, OAuth diventasse il protocollo principe alla base del social login.
I vantaggi derivanti dal social login sono molteplici, come ad esempio:
- la personalizzazione dei contenuti sulla base della profilazione dell’utente;
- la possibilità di accedere alla piattaforma con account social differenti;
- la pre-validazione delle email degli utenti da parte delle piattaforme social;
- la possibilità di collegare un account alla piattaforma senza costringere l’utente a registrarsi;
- la rapidità del processo di registrazione.
In questa guida, ci si concentrerà su come integrare il social login nelle proprie applicazioni mobile sfruttando OAuth 2.0 e i principali social media: Facebook, Twitter, e Google.
Prerequisiti
Per affrontare al meglio questa guida, è necessario avere installato:
| Tool | Dettagli |
|---|---|
| Android Studio | 2.3.3 |
| Android | API 15 o superiori e la SDK di Google Play Services |
| Xcode | 8 o superiore |
| Account Developer | Twitter, Facebook, Google |
Il protocollo OAuth
Definito per la prima volta nel 2006 da Baline Cook, OAuth si è affermato nel corso degli anni come protocollo di autorizzazione sicuro che abilita le applicazioni di terze parti a ottenere un accesso limitato all’account social degli utenti attraverso un servizio HTTP. In particolare, il protocollo sfrutta la possibilità di affidare l’autenticazione al servizio che ospita l’account dell’utente, autorizzando le applicazioni ad accedere alle informazioni permission-based.
Il protocollo OAuth definisce i seguenti quattro ruoli:
| Ruolo | Dettagli |
|---|---|
| Resource Owner (User) | È l’utente che autorizza un’applicazione ad accedere al proprio account. L’accesso è limitato al solo scopo di concedere l’autorizzazione e il recupero delle informazioni base. |
| Resource Server (RS) | È il server che ospita gli account degli utenti (ad esempio quello di un social network) e autorizza il server delle applicazioni di terze parti. |
| Client (Application) | È l’applicazione che vuole accedere all’account dell’utente previa autorizzazione di quest’ultimo e validazione dell’autorizzazione da parte del RS. |
| Authorization Server (AS) | È il server che verifica l’identità dell’utente, rilascia l’access token per l’applicazione ed effettua il ruolo di intermediario tra il Client e il Resource Owner. |
Queste entità interagiscono tra loro come nello schema riportato in Figura 2.
In particolare, l’applicazione richiede all’utente l’autorizzazione per accedere all’account e ai relativi dati. Una volta autorizzata, l’applicazione è in possesso di un permesso, chiamato Authorization Grant (AG), per richiedere l’access token all’AS.
L’applicazione comunica l’AG e la sua identità all’AS, che li verifica. Se la validazione va a buon fine, l’AS eroga un access token per l’applicazione, completando così il processo di autorizzazione.
L’applicazione può contattare l’RS per richiedere le risorse relative all’account dell’utente, inoltrando il proprio access token per l’autenticazione. Se l’access token è valido, l’RS fornirà all’applicazione le risorse richieste.
L’access token e l’authentication grant sono gli elementi fondamentali per la corretta esecuzione del protocollo. Nello specifico:
| Authorization Grant | È l’autorizzazione dell’utente a far accedere l’applicazione alle proprie risorse protette. Esistono quattro diversi tipi di AG che sono: authorization code, implicit, resource owner password credentials e client credentials. Per ulteriori dettagli in merito si rimanda al Requests for Comments (RFC) 6749. |
| Access Token | Indica le credenziali necessarie per accedere alle risorse protette ed è una stringa che rappresenta l’autorizzazione del client. Questo token fornisce un livello di astrazione che permette di sostituire differenti approcci di autorizzazione con un singolo token, che può essere riconosciuto dal RS. Grazie a questa astrazione è possibile rilasciare dei token più restrittivi dell’AG. eliminando del tutto la necessità da parte dell’RS di supportare diverse tipologie di autenticazione. |
Questo processo si basa sull’assunto che l’applicazione sia identificata sia dall’AS sia dall’RS. Infatti, prima di utilizzare il protocollo OAuth, è necessario che l’applicazione sia registrata presso il servizio di riferimento. Tale operazione deve essere effettuata accedendo alla sezione developer o API del servizio che si desidera usare (Facebook, Google, …) e fornendo informazioni quali nome dell’applicazione e del relativo pacchetto.
