Il grande compromesso storico del social login

Collezionando app per gli universi cloud che popolano il mercato (App Store, Windows Store, Play Store…) ci ritroviamo con una miriade di servizi, alcuni accessibili out-of-the-box, altri previa registrazione dell’utente.
Le funzioni accedi con Facebook/Twitter/Google+/… delegano l’accesso al servizio a terzi. Perché?
Prima dell’avvento del mercato delle app così come siamo abituati a intenderlo oggi, i provider di servizi che richiedevano una registrazione dell’utente per la fornitura dei propri servizi proponevano gelosamente un meccanismo di registrazione privato.
Oggi abbiamo invece troviamo la possibilità di procedere alla registrazione –ovvero di accedere al servizio – per mezzo di meccanismi terzi: accedi con Facebook, accedi con Twitter e così via.
Sono sistemi che prendono il nome di social login e non sono in molti ad offrirlo. Ho infatti sufficiente spazio per elencarli tutti:

• AOL
• Facebook
• Foursquare
• Google+
• Hyves
• LinkedIn
• LiveJournal
• Myspace
• Renren (人人网)
• Vkontakte (ВКонтакте)
• Twitter
• Yahoo!
• QQ
• Sina Weibo
• Plurk
• WordPress
• Paypal

Ma perchè mai questo cambio di direzione? Potremmo dare diverse risposte al quesito trattandosi in realtà si tratta di una combinazione di fattori, ma uno su tutti è il principale: il raggiungimento del break even point tra costi e benefici per la costruzione di un database utenti personale, e relativa tecnologia di accesso.
Cosa comporta il costruire un database di utenti privato? Costi, in primis. Il servizio di login di per sé è, appunto, un servizio a parte. Comporta infatti un database, un canale di comunicazione (che può essere un web service), una infrastruttura di rete che possa garantire l’accesso uniforme al servizio, ma soprattutto un involucro sicuro, capace di proteggere le password degli utenti oltre ad altri eventuali dati sensibili raccolti.
Insomma, per fornire un servizio A devi mettere in piedi un servizio B che potrebbe costare più di A nel caso in cui B non generasse profitto ed A fosse sufficientemente economico da mantenere.
Alla luce del fatto che il produttore dell’app di turno possa trovarsi nella condizione di:

1. risparmiare i costi di produzione del servizio di login;
2. scaricare a terzi la gestione del servizio ed annessa responsabilità (i dati utente sono un po’ la patata bollente di Internet);
3. godere dei vantaggi derivati dalla competizione tra gestori di servizi social login, quali ad esempio l’accesso alle informazioni pubbliche dell’utente, friend-list eccetera.

In un mondo in cui una importante parte di sviluppatori di app è composta da startup, piccole imprese e laboratori, è spesso preferito evitare i costi di gestione di un servizio di login quando possibile, rinunciando in tutto o in parte alla monetizzazione dell’utente.
Possiamo quindi desumere che il social login sia derivato dall’abbattimento della soglia di ingresso nel mondo dello sviluppo di mobile app, dal valore aggiunto prodotto dai colossali database utenti dei social network, più la concorrenza tra essi stessi.
Abbiamo tutti da guadagnarci, soprattutto l’utente finale. In questo modo può infatti aggregare le credenziali di accesso dietro un unico account che, pur trattandosi logicamente di un SPOF (single point of failure), rimane comunque tecnicamente più affidabile – in questo caso – di N servizi minori.