Penso che a tutti sia capitato, prima o poi, di provare la frustrazione di dover gestire più password per i diversi siti a cui ci si è iscritti. Il che spesso porta a dimenticare la password per questo o quel sito, e a doverla rigenerare praticamente ogni volta che si va ad accedere al sito e compare un messaggio del tipo “Spiacenti, questa password non corrisponde a questo account utente” ARGGHHHH!!! Ero sicuro al 100% che fosse la mia password!
Una soluzione è dire al browser di ricordare per te le informazioni di accesso, così che quando ti viene presentata la schermata di login, trovi già inseriti il nome utente e la password. Certo, anche se questa potrebbe essere una soluzione su un computer completamente privato, esporrebbe però i tuoi dati personali se usi un computer condiviso o se il tuo computer privato finisce nelle mani di qualcun altro. Quindi probabilmente non è la soluzione migliore. Un’altra soluzione sarebbe avere un posto dove annotare tutti i nomi utente e le password per tutti i siti web a cui ti sei registrato: anche se è un po’ più sicura del metodo precedente, non è comunque sicura al 100% ed è anche una gran seccatura…
Ebbene, per superare questo limite alcune persone in gamba hanno iniziato a proporre una soluzione che permettesse agli utenti di accedere a siti web diversi con le stesse “credenziali”, o meglio tramite un “provider affidabile”. Questo nuovo protocollo è stato chiamato “OpenID”, e all’epoca è stata certamente un’idea rivoluzionaria, soprattutto perché era anche una tecnologia open-source. Tuttavia non è mai diventato davvero popolare tra il grande pubblico, perché non era abbastanza intuitivo. Però ha comunque aperto la strada all’esperienza del “single sign-in”. Molti dei grandi provider usano effettivamente OpenID, anche se magari non te ne rendi conto. Se hai un account Google, hai un account OpenID. Se hai un account WordPress, hai un account OpenID…
Poi è iniziata l’era dei “grandi provider”. Se molte persone non hanno sentito parlare molto di “OpenID”, probabilmente hanno sentito parlare di Google, di Facebook, di Twitter… Se non li conoscono, probabilmente non sono il tipo di persone che va spesso sul web o che comunque accede ai siti. Se un indirizzo email è già stato verificato da uno di questi grandi provider, possiamo più o meno fidarci della loro verifica; quindi perché non permettere a qualcuno di accedere a un sito web usando un meccanismo di autenticazione di un grande provider che ti dice che sì, questa email è stata verificata? In questo modo le persone che usano spesso le credenziali per Google o per Facebook e probabilmente se le ricordano non devono crearne di nuove per accedere al tuo sito web: accedono semplicemente con il loro account Google o Facebook, e il gioco è fatto.
Ebbene, questa soluzione del “provider di account” ha funzionato piuttosto bene negli ultimi anni, soprattutto da quando il web è diventato sempre più “social”: questo modo di accedere tramite provider affidabili era anche un modo di accedere tramite i provider dei “contenitori social”, e ha aperto possibilità per rendere il proprio sito web più interattivo dal punto di vista sociale, o per farlo interagire con quei contenitori social, dando al proprio sito web maggiore visibilità, rendendo la visita al sito più interattiva, interessante e socialmente coinvolgente…
Ebbene, quella sembrava una buona soluzione, ed è ancora usata parecchio. Ma ha anche alcuni svantaggi. Anzitutto, le API per sviluppatori messe a disposizione da questi contenitori social tendono a cambiare piuttosto spesso. Il che significa che un webmaster deve continuamente modificare il codice del suo meccanismo di accesso, cercando di stare al passo con tutti i cambiamenti delle API di questi diversi contenitori social. E inoltre, ogni contenitore social crea la propria API con i propri meccanismi, che, pur essendo abbastanza simili, hanno ciascuno il proprio flusso specifico. Il che significa che un webmaster deve tenere conto dei diversi meccanismi di autenticazione forniti dai diversi contenitori social o provider di account. A volte il mal di testa può essere evitato grazie a terze parti che si offrono di occuparsi di tutta la codifica dei meccanismi di autenticazione per i diversi contenitori. Ma anche questo ha i suoi svantaggi: devi fidarti della terza parte che prende nelle proprie mani il meccanismo di registrazione e di accesso del tuo sito web, e quindi potenzialmente monitora i profili personali dei tuoi utenti… E se la terza parte ha dei tempi di inattività? Potresti non avere un meccanismo di login disponibile sul tuo sito web a causa dei tempi di inattività della terza parte… E poi, ultimo ma non meno importante, usare questo tipo di meccanismo di autenticazione, con o senza una terza parte, tende ad appesantire il caricamento iniziale del tuo sito web, perché effettua ogni genere di chiamate a questi provider social, scaricando le loro API javascript e così via. E anche se gran parte di questo caricamento javascript dovrebbe essere asincrono, così da non rallentare il caricamento della tua pagina web, nella mia esperienza c’era sempre qualcosa che lo rallentava (e puoi effettivamente vedere la barra di stato del tuo browser bloccata su qualcosa come “tentativo di connessione a something.facebook.com…”).
Dunque abbiamo alcune nuove tecnologie interessanti e alcuni progressi interessanti nel modo in cui le persone interagiscono con i siti web e tra loro sul web, ma questi nuovi progressi hanno comunque i loro svantaggi. Come affrontiamo questi svantaggi?
Ebbene, ho appena scoperto una nuova proposta del team di Mozilla, che supera molti dei problemi menzionati sopra. È un nuovo meccanismo di autenticazione inizialmente chiamato BrowserID, ora chiamato “Persona”, che ti permette di autenticare il tuo indirizzo email con questo servizio e, una volta autenticato, ti permette di accedere a qualsiasi sito web usando questo servizio senza dover ricordare ogni volta una password. Niente più mal di testa per codificare i meccanismi di autenticazione per diversi contenitori social, niente più pagine appesantite da diversi download javascript da diversi contenitori social… Se vuoi ancora avere interazioni social sul tuo sito web puoi comunque usare tutte le API dei contenitori social che desideri per questo, ma il tuo meccanismo di login è stato enormemente semplificato. E se diversi browser web cominciano ad adottare questa nuova tecnologia, probabilmente renderà questo meccanismo di autenticazione molto più semplice per tutti.
Puoi trovare maggiori informazioni qui: http://identity.mozilla.com/post/7616727542/introducing-browserid-a-better-way-to-sign-in
e qui:
https://developer.mozilla.org/en-US/docs/Persona
Puoi verificare la tua email per l’uso con BrowserID qui:
https://login.persona.org/
Se usi wordpress, c’è un plugin BrowserID che abiliterà l’autenticazione BrowserID (o Persona) sul tuo sito web WordPress: http://wordpress.org/extend/plugins/browserid/.
L’ho appena installato anch’io (ho anche contribuito con una traduzione italiana), e non avrebbe potuto essere più semplice. Mi sono liberato di Janrain e sto usando BrowserID al suo posto, e all’improvviso il mio sito web è come dieci volte più veloce. Inoltre non devo preoccuparmi di terze parti che si frappongono e gestiscono i dati dei miei utenti.