Accedi con Google: cosa riceve davvero il sito

Premere il pulsante Accedi con Google, che appare su un amplissimo numero di siti web, può dare l’impressione di consegnare al sito una parte consistente del proprio account Google. In realtà, nel caso più comune, il meccanismo trasferisce un insieme piuttosto limitato di informazioni: quanto basta per identificare l’utente e creare o recuperare il suo profilo sul servizio.

Il punto importante è distinguere due operazioni spesso confuse tra loro: autenticazione e autorizzazione. Dire a un sito “sono davvero questa persona” non equivale ad autorizzarlo a leggere Gmail, Google Drive, Calendar o gli altri dati associati all’account.

Dietro ad meccanismo alla base del funzionamento di Accedi con Google troviamo principalmente OpenID Connect (OIDC), costruito sopra OAuth 2.0. OAuth è utilizzato quando un’applicazione vuole ottenere anche il permesso di utilizzare determinate API Google.

Accedi con Google non significa consegnare la password

Quando un sito utilizza correttamente il sistema Accedi con Google, le credenziali dell’account Google non transitano mai attraverso il server del sito. L’autenticazione avviene presso Google; al termine della procedura di autenticazione, Google restituisce all’applicazione una prova crittografica dell’identità dell’utente.

Il servizio esterno NON riceve:

• la password Google;
• i codici utilizzati per l’autenticazione a due fattori;
• le passkey eventualmente memorizzate nell’account;
• i cookie della sessione Google.

Il principio è proprio quello di evitare che ogni sito debba conoscere e conservare una nuova password.

Dal punto di vista tecnico, Google consegna al sito un token ID, tipicamente un JSON Web Token (JWT) firmato digitalmente. Il server dell’applicazione verifica la firma e controlla alcuni valori del token per stabilire che sia stato realmente prodotto da Google e destinato proprio a quella applicazione.

Google raccomanda di usare il claim sub come identificatore principale dell’utente: sub, abbreviazione di “subject“, è un valore univoco associato all’account Google e pensato proprio per permettere all’applicazione di riconoscere la stessa persona negli accessi successivi. L’indirizzo email, invece, è un dato del profilo: può cambiare nel tempo e quindi non è una buona chiave tecnica su cui basare l’identità dell’account locale. Il sito dovrebbe collegare l’utente al valore sub e trattare l’email come un’informazione modificabile, non come l’identificatore definitivo.

Quali informazioni contiene il token ID Google

Un token ID contiene una serie di claim, ossia affermazioni firmate dal provider di identità. Può quindi includere informazioni simili alle seguenti:

sub
email
email_verified
name
given_name
family_name
picture
hd
iat
exp

Abbiamo già parlato dell’identificatore sub, oggetto univoco che consente al sito di riconoscere lo stesso utente anche negli accessi successivi.

Quali informazioni sono trasferite al sito

A seconda della configurazione e dei claim richiesti, il sito può ricevere anche:

• email, cioè l’indirizzo principale associato all’account;
• email_verified, che indica se Google considera quell’indirizzo verificato;
• name, given_name e family_name, ossia nome completo, nome e cognome;
• picture, un URL che punta all’immagine del profilo;
• hd, in alcuni casi, per indicare il dominio Google Workspace associato all’account;
• iat ed exp, che indicano rispettivamente quando il token è stato generato e quando scade.

Google documenta una durata di circa un’ora per il token ID. È però importante non confondere la scadenza del token con la sessione creata dal sito: dopo aver verificato il token, il servizio può creare un proprio cookie di sessione e mantenere l’utente autenticato secondo le proprie regole.

Quindi il sito vede nome, email e foto?

Dipende da quali informazioni l’applicazione ha chiesto a Google durante il login.

I claim descritti poco sopra sono i singoli dati che Google può inserire nel token ID; gli scope, invece, servono a stabilire quali gruppi di informazioni l’applicazione richiede.

Nel caso tipico di Accedi con Google compaiono tre scope OpenID Connect: openid, email e profile.

openid indica che l’applicazione vuole usare OpenID Connect per autenticare l’utente. email permette di ottenere informazioni relative all’indirizzo email principale; profile consente di ricevere alcuni dati di base del profilo, come nome e immagine.

Gli scope dicono a Google quali informazioni possono essere richieste, mentre i claim rappresentano i dati effettivamente restituiti all’applicazione. Per esempio, con email e profile il token ID può contenere claim come sub, email, email_verified, name, given_name, family_name e picture.

Un sito che propone semplicemente Continua con Google può quindi ricevere l’identificatore dell’account Google, l’indirizzo email e alcune informazioni di base del profilo.

Le differenze tra token ID e access token

Come abbiamo visto in precedenza, in token ID serve a dimostrare chi è l’utente. Un access token serve invece ad accedere a una risorsa o a un’API.

Se un’applicazione riceve soltanto un token ID per autenticare l’utente, non può prendere quel token e utilizzarlo liberamente per scaricare i messaggi Gmail o leggere i documenti su Drive. Per accedere a servizi aggiuntivi occorre un’autorizzazione OAuth e servono gli scope appropriati.

Per esempio, Google definisce scope distinti come i seguenti:

https://www.googleapis.com/auth/gmail.readonly
https://www.googleapis.com/auth/drive.readonly
https://www.googleapis.com/auth/calendar.readonly

Un’applicazione che chiede gmail.readonly sta domandando un permesso profondamente diverso rispetto alla semplice richiesta openid email profile: nel primo caso vuole poter leggere i messaggi e i metadati della casella Gmail tramite API; nel secondo chiede soltanto le informazioni necessarie per autenticare l’utente e identificarlo, come indirizzo email e dati di base del profilo.

L’elenco degli scope OAuth pubblicato da Google mostra quanto granulare possa diventare il sistema: esistono autorizzazioni specifiche per Gmail, Drive, Calendar, YouTube, Google Foto e molti altri servizi.

Il pulsante Google non dà automaticamente accesso a Gmail

Quando, di recente, si è tornati a parlare di account Google compromessi e di applicazioni collegate a Gmail, è riemerso un falso mito purtroppo piuttosto comune: usare Accedi con Google non significa concedere automaticamente a un sito il permesso di leggere la posta, accedere a Drive, al calendario, prendere possesso di un account YouTube e così via.

Parlando di Gmail, come abbiamo visto, serve uno scope OAuth specifico per autorizzare l’applicazione terza ad accedere al contenuto della casella di posta. Google, per esempio, definisce https://www.googleapis.com/auth/gmail.readonly come il permesso che consente a un’applicazione di visualizzare i messaggi e le impostazioni di Gmail. Esistono poi scope ancora più estesi, come gmail.modify, che permette anche di modificare i messaggi, oppure https://mail.google.com/, che concede accesso molto ampio alla casella.

Sottolineiamo che la semplice autenticazione tramite openid email profile è un’altra cosa: serve a identificare l’utente e a ottenere alcune informazioni di base sul suo profilo. Google stessa invita l’utente a controllare con attenzione quali dati e quali permessi un’applicazione di terze parti sta richiedendo prima di autorizzarla.

Alcuni scope che consentono l’accesso a dati particolarmente delicati sono inoltre classificati da Google come sensitive o restricted e possono richiedere verifiche aggiuntive dell’applicazione.

Un sito non riceve neppure il “profilo pubblicitario Google”

Un’altra convinzione piuttosto diffusa consiste nell’immaginare che il login Google trasmetta al sito il profilo utilizzato per la personalizzazione pubblicitaria. Non funziona così.

Il token di autenticazione non contiene, per esempio, una lista del tipo: interessato a tecnologia, interessato ad automobili, fascia di reddito stimata, cronologia delle ricerche, siti visitati, annunci visualizzati e via dicendo.

Ciò non significa che il sito non possa costruire autonomamente un proprio profilo dopo il login: una volta riconosciuto l’utente, può infatti collegare allo stesso account le pagine visitate, gli acquisti, le preferenze, le ricerche interne e qualunque altra attività che il servizio raccolga nel rispetto delle proprie condizioni e della normativa applicabile.

Ma quei dati sono eventualmente raccolti dal sito, non consegnati automaticamente da Google attraverso il login.

Qual è il significato di email verificata?

Tra i claim più interessanti compare, come abbiamo visto, email_verified. Il valore email_verified: true indica che Google ha verificato l’indirizzo associato all’account.

Google spiega che, per gli indirizzi @gmail.com, può considerarsi autorevole rispetto all’account. Lo stesso vale di norma per gli account Google Workspace quando si ha email_verified: true e compare anche il claim hd.

Per un account Google creato utilizzando invece un indirizzo esterno, per esempio appartenente a un altro provider di posta, email_verified può indicare che Google ha verificato quell’indirizzo durante la registrazione. Non equivale alla garanzia di un effettivo controllo sulla proprietà della casella esterna!

Il sito può conoscere il numero di telefono associato all’account Google?

Con il normale openid email profile, no. Google dispone di API che permettono di accedere a categorie aggiuntive di informazioni personali, ma richiedono scope specifici.

La People API, per esempio, definisce autorizzazioni separate per informazioni come numeri telefonici, indirizzi, data di nascita e dati relativi all’organizzazione. La separazione è intenzionale: il fatto che Google conosca un’informazione non significa che la trasmetta a qualsiasi applicazione utilizzata per il login.

Lo stesso principio vale per i contatti: un’applicazione non ottiene la rubrica semplicemente perché l’utente ha effettuato l’accesso tramite Google.

Nemmeno la posizione geografica dell’utente fa parte del normale pacchetto di informazioni di Accedi con Google. Il sito può naturalmente conoscere alcuni dati tecnici propri della connessione, a partire dall’indirizzo IP pubblico e da lì stimare la posizione geografica dell’utente.

Google sa invece che abbiamo effettuato l’accesso a quel sito?

Qui la prospettiva va capovolta. Per poter autenticare l’utente, Google deve partecipare alla procedura: il provider conosce quindi necessariamente alcune informazioni relative alla richiesta di autenticazione, tra cui l’applicazione che sta richiedendo l’identità e il client OAuth/OpenID Connect coinvolto.

Non sarebbe possibile firmare un token destinato a uno specifico sito senza sapere a quale applicazione quel token è destinato.

Il claim aud, per esempio, identifica l’audience, cioè il destinatario per il quale il token è stato emesso: il sito deve controllare che quel valore corrisponda al proprio client ID prima di accettare il token ID.

Usare quindi Google come identity provider riduce la quantità di password distribuite tra molti servizi, ma introduce Google nel processo di autenticazione.

Autenticazione oggi, autorizzazione domani

Esiste poi un aspetto importante sul quale soffermarsi a riflettere: un sito può inizialmente chiedere soltanto openid email profile e successivamente proporre una funzione del tipo “Collega Google Calendar“. A quel punto parte una seconda procedura OAuth e l’applicazione può richiedere, per esempio, un’autorizzazione relativa a Calendar.

È una pratica incoraggiata da Google stessa attraverso il principio dell’incremental authorization: chiedere un permesso quando serve davvero anziché presentare all’utente, al primo accesso, una lunga lista di autorizzazioni scollegate dalla funzione che sta utilizzando.

Per questo motivo non basta ricordare di avere usato in passato Accedi con Google: bisogna distinguere il login dalle eventuali autorizzazioni concesse successivamente alla stessa applicazione.

OpenID Connect è simile a mostrare un documento d’identità. Una fonte ritenuta affidabile (in questo caso Google) conferma chi siamo e fornisce alcune informazioni anagrafiche.

OAuth è simile a consegnare una chiave con poteri limitati. La chiave può aprire soltanto alcune porte e le sue capacità dipendono dai permessi che l’utente ha concesso (scope).

Accedi con Google utilizza normalmente il primo meccanismo per l’identità; quando un’applicazione vuole fare qualcosa con i dati Google dell’utente, entra in gioco il secondo.

Il dato più importante è quello che il sito raccoglie dopo il login

Limitarsi a verificare cosa Google trasmette durante l’autenticazione non basta per valutare la privacy di un servizio.

Dopo l’accesso il sito può costruire una propria cronologia associata a quell’utente: articoli letti, ricerche, acquisti, preferenze, dispositivi utilizzati, indirizzi IP e molte altre informazioni derivanti dall’utilizzo del servizio. Il login Google rende più semplice collegare queste attività alla stessa identità nel tempo, perché fornisce un identificatore stabile.

Oltre a chiederci “cosa comunica Google al sito?”, è bene porsi anche un secondo quesito: “cosa farà il sito con l’identità che Google gli ha appena confermato?”

Nel login standard, la risposta alla prima domanda è relativamente rassicurante: identificatore, email e alcune informazioni di base del profilo. Per tutto il resto servono ulteriori autorizzazioni o fonti di dati.

Sulla seconda domanda – conservazione, profilazione, condivisione e utilizzo delle informazioni raccolte dal servizio – si gioca gran parte della reale differenza in termini di privacy.

Come revocare l’accesso e cosa succede ai dati già condivisi

Google permette di controllare e rimuovere in qualsiasi momento i collegamenti con applicazioni e servizi di terze parti. Il punto di partenza è la pagina App collegate dell’account Google che presenta tre categorie apparentemente simili ma descrivono situazioni molto diverse:

• Accedi con Google raccoglie i siti e le applicazioni sui quali utilizziamo l’account Google per autenticarci. In questo caso è Google a confermare al servizio esterno chi siamo, condividendo le informazioni previste dal login, per esempio identificatore dell’account, email e dati di base del profilo. Rimuovere il collegamento significa interrompere l’utilizzo di Accedi con Google per quel servizio; non equivale però a cancellare l’account creato sul sito né i dati che quest’ultimo ha già memorizzato.
  
• Account collegato descrive invece la situazione opposta: è Google ad avere accesso a un account che possediamo presso un servizio esterno. Un esempio è il collegamento di un servizio di streaming musicale, così che un prodotto Google possa interagire con quell’account e utilizzare alcune sue funzioni. Eliminando il collegamento, Google perde le autorizzazioni verso il servizio di terze parti.
• Accesso a contiene le informazioni più direttamente collegate agli scope OAuth descritti in precedenza: mostra le applicazioni e i servizi di terze parti ai quali abbiamo concesso l’accesso a determinate informazioni o funzioni del nostro account Google. Qui possono quindi comparire applicazioni autorizzate ad accedere, per esempio, a Google Calendar, Drive, Gmail o altri prodotti. Se si rimuove l’accesso, la terza parte non può più utilizzare quelle autorizzazioni per interrogare l’account Google, verificarne e modificarne il contenuto.

È soprattutto quest’ultima categoria che conviene controllare con attenzione quando si vogliono verificare permessi OAuth concessi in passato a Gmail, Drive, Calendar o ad altri servizi Google. Anche in questo caso, però, la revoca impedisce gli accessi futuri: non elimina automaticamente eventuali dati che l’applicazione ha già copiato e conservato sui propri sistemi.

Come chiedere la cancellazione dei dati ai sensi del GDPR

Rimuovere un collegamento dalla pagina Google dedicata alle applicazioni di terze parti serve a impedire nuovi accessi, ma non ordina automaticamente al sito terzo di cancellare ciò che ha già acquisito.

Se, per esempio, un servizio ha ottenuto tramite Accedi con Google nome, indirizzo email, foto del profilo e identificatore dell’account, tali informazioni possono essere già state copiate nei suoi database. Lo stesso vale per eventuali dati ottenuti tramite API Google mentre un’autorizzazione OAuth era attiva.

Google non può cancellare quei dati al posto del servizio che li ha ricevuti: bisogna rivolgersi direttamente al titolare del trattamento, cioè al soggetto che decide finalità e modalità con cui quei dati personali sono utilizzati.

Per gli utenti nell’Unione Europea entra quindi in gioco l’articolo 17 del GDPR, che disciplina il diritto alla cancellazione. Uno dei casi più comuni nei quali l’interessato può chiedere la cancellazione e il titolare deve procedere senza ingiustificato ritardo, riguarda dati non più necessari rispetto allo scopo per cui erano stati raccolti. Se l’utente non intende più utilizzare il servizio, può chiedere la cancellazione dell’account e dei dati personali associati, facendo valere il diritto previsto dall’articolo 17 del GDPR quando non sussistono ulteriori basi giuridiche che ne giustifichino la conservazione.

La cancellazione può essere richiesta anche quando il trattamento si basava sul consenso, l’utente lo revoca e non esiste un’altra base giuridica che consenta di continuare a conservare i dati.

Quando la cancellazione non può essere totale

Il diritto alla cancellazione, però, non è assoluto. Un servizio può avere ragioni giuridicamente valide per conservare almeno una parte delle informazioni. Può accadere, per esempio, quando una legge impone determinati periodi di conservazione oppure quando i dati risultano necessari per accertare, esercitare o difendere un diritto in sede giudiziaria.

Un caso concreto aiuta a capire la differenza. Se utilizziamo Accedi con Google su un sito di e-commerce e successivamente chiudiamo l’account, possiamo chiedere che il profilo e i dati non più necessari siano cancellati. Il venditore potrebbe però dover conservare per il periodo previsto dalla legge documenti fiscali o informazioni relative alle transazioni.

La sequenza corretta è quindi questa: prima si revoca da Google il login federato o l’accesso OAuth per impedire ulteriori acquisizioni; poi, se si vogliono eliminare anche le informazioni già trasferite, si presenta una richiesta di cancellazione direttamente al servizio che le conserva.