Il pulsante Accedi con Google compare su un numero enorme di siti e app, e molti utenti temono che premerlo equivalga a consegnare mezzo account Google a uno sconosciuto. La realta’ tecnica e’ molto piu’ contenuta: quel passaggio trasferisce un pacchetto minimo di informazioni, giusto quelle necessarie a identificare la persona. Google e’ esplicita nel dire che Accedi con Google non condivide la password del tuo Account Google, e le specifiche OpenID Connect confermano che, con gli scope standard, il sito non riceve ne’ Gmail, ne’ Drive, ne’ Calendar. Vediamo esattamente cosa arriva al sito, cosa no, e come togliere l’accesso a un servizio che non usi piu’.
TL;DR — Accedi con Google in 5 punti
- Il sito riceve un token ID firmato (JWT), non la password ne’ i cookie della sessione Google.
- Con gli scope
openid email profilearrivano al massimo: ID univoco (sub), email, nome, foto profilo, dominio Workspace. - Il token ID non e’ un access token: non serve a leggere Gmail, Drive o Calendar.
- Per accedere ai dati Google servono scope OAuth espliciti come
gmail.readonlyodrive.readonly, con consenso separato. - Puoi revocare Accedi con Google in qualsiasi momento da myaccount.google.com/connections.
Indice
- Come funziona Accedi con Google, in una riga
- Quali dati riceve il sito nel token ID
- ID token vs access token: la differenza che conta
- Cosa il sito NON riceve (Gmail, Drive, numero, profilo pubblicitario)
- Tabella: scope standard vs scope sensibili
- Il rischio vero: il phishing del consenso OAuth
- Come revocare Accedi con Google a un sito
- Domande frequenti
Come funziona Accedi con Google, in una riga
Accedi con Google e’ un’implementazione di OpenID Connect (OIDC), un livello di identita’ costruito sopra OAuth 2.0. La distinzione chiave e’ tra autenticazione (dimostrare chi sei) e autorizzazione (permettere a un’app di fare qualcosa con i tuoi dati Google): il pulsante di login fa solo la prima cosa, non la seconda.
Quando premi il pulsante, il browser ti reindirizza a Google. Google verifica la tua identita’ (con password, passkey o 2FA), poi restituisce al sito una prova crittografica che sei tu. Il sito non vede mai la password, i codici 2FA, le passkey memorizzate ne’ i cookie della sessione Google. E’ proprio il senso del meccanismo: evitare che ogni sito conservi una nuova password.
Quali dati riceve il sito nel token ID
La prova di identita’ arriva come ID token, un JSON Web Token firmato digitalmente (JWT) definito dalla specifica OpenID Connect Core 1.0. Il server del sito verifica la firma con le chiavi pubbliche di Google e controlla alcuni valori per accertarsi che il token arrivi davvero da Google e sia destinato a quell’applicazione.
Con la richiesta standard di Sign in with Google — scope openid email profile — i claim effettivamente restituiti da Google sono, secondo la documentazione ufficiale Google Identity:
sub— ID univoco Google della persona, stabile nel tempo. E’ il claim da usare come identificatore principale, perche’ non cambia mai.email— indirizzo email associato all’account.email_verified— booleano che indica se Google ha verificato quell’email.name,given_name,family_name— nome, nome proprio, cognome del profilo.picture— URL dell’immagine profilo.hd— dominio Google Workspace, presente solo se sei su un account aziendale.iss,aud,iat,exp— emittente (accounts.google.com), destinatario, momento di emissione e scadenza del token.
Il token ID ha una scadenza breve, tipicamente circa un’ora, ma non e’ la sessione del sito: dopo la verifica, il servizio crea un proprio cookie di sessione e ti tiene collegato secondo le sue regole.
ID token vs access token: la differenza che conta
Un errore comune e’ confondere due oggetti diversi che Google puo’ emettere:
- ID token — dimostra chi e’ l’utente. E’ un JWT firmato che il sito legge per identificare la persona. Non consente di chiamare API.
- Access token — autorizza a fare qualcosa con i dati Google. E’ opaco (va trattato come un blob, anche se somiglia a un JWT). Serve per chiamare API come Gmail o Drive.
Il login genera solo un ID token; l’autorizzazione a leggere risorse specifiche richiede un access token separato, ottenuto con scope dedicati e con un consenso esplicito dell’utente. Un access token per gmail.readonly e uno per openid email profile sono due oggetti profondamente diversi, con permessi profondamente diversi.
Cosa il sito NON riceve
Con la sola pressione del pulsante Accedi con Google, il sito non ottiene:
- La tua password Google, ne’ i codici della verifica in due passaggi, ne’ le passkey memorizzate nell’account.
- I cookie della tua sessione Google.
- Gmail, Google Drive, Calendar, Foto, YouTube o qualunque altro servizio Google: per quelli servono scope OAuth espliciti come
gmail.readonly,drive.readonly,calendar.readonly, che presentano una schermata di consenso distinta. - Il numero di telefono: con
openid email profilenon viene trasmesso. Servono scope specifici della People API, che tiene separati numeri, indirizzi, data di nascita e dati sull’organizzazione. - Il tuo profilo pubblicitario: il token non contiene liste di interessi, cronologia di ricerca o annunci visualizzati. Il sito puo’ costruirsi un profilo suo osservandoti mentre lo usi, ma quei dati li raccoglie lui, non glieli passa Google.
Tabella: scope standard vs scope sensibili
| Scope richiesto | Cosa vede il sito | Classe |
|---|---|---|
openid |
Solo il claim sub (ID univoco). |
Base identita’ |
email |
Indirizzo email e email_verified. |
Profilo base |
profile |
Nome, cognome, foto profilo, URL profilo, locale. | Profilo base |
gmail.readonly |
Lettura messaggi e metadati della casella Gmail. | Sensitive / restricted |
drive.readonly |
Lettura di file e metadati su Google Drive. | Sensitive / restricted |
calendar.readonly |
Lettura eventi Google Calendar. | Sensitive |
Gli scope sensitive e restricted di Google richiedono verifiche aggiuntive per l’app che li domanda, e all’utente viene mostrata una schermata di consenso separata rispetto al login. La logica di sicurezza qui e’ quella dei permessi granulari introdotti da Google negli ultimi anni: puoi concedere alcune autorizzazioni e negarne altre.
Il rischio vero: il phishing del consenso OAuth
Il pericolo che vale la pena conoscere non e’ Accedi con Google in se’, ma il cosiddetto OAuth consent phishing. Funziona cosi’: un attaccante registra un’app malevola su Google Cloud o Microsoft Entra e ti manda un link di consenso che sembra legittimo, perche’ e’ ospitato sul provider reale. Se acconsenti, l’app riceve token OAuth con gli scope che ha chiesto — magari gmail.readonly — e puo’ continuare a leggere i tuoi dati anche dopo un cambio password, perche’ non ha bisogno delle credenziali.
Come difesa, leggi sempre la schermata di consenso: chi e’ l’app (dominio verificato?), quali permessi chiede, se il permesso e’ coerente con il servizio. Un consenso gmail.readonly a un sito che dovrebbe solo identificarti e’ un segnale rosso enorme, allo stesso modo delle trappole di social engineering che si nascondono dentro offerte di lavoro plausibili.
Come revocare Accedi con Google a un sito
Se non usi piu’ un servizio a cui hai fatto login con Google, revocare l’accesso e’ l’igiene minima. La guida ufficiale Google indica questa procedura:
- Vai su myaccount.google.com/connections.
- Seleziona Accedi con Google e poi l’app o il servizio che ti interessa.
- Tocca Visualizza dettagli e poi Elimina collegamento e conferma.
La modifica e’ immediata dal lato Google: il sito non potra’ piu’ usare Accedi con Google per farti entrare. Attenzione: la revoca non cancella l’account che hai gia’ creato su quel sito, ne’ i dati che il sito ha memorizzato. Se vuoi rimuovere anche quelli, devi passare dalle impostazioni del sito stesso.
Ti interessa il modo in cui identita’ digitali e autenticazione stanno cambiando?
Sul canale @tuttelevitediunmaker parlo di privacy, passkey e OAuth con esempi pratici, e su Patreon trovi approfondimenti e checklist scaricabili. #tuttelevitediunmaker
Domande frequenti su Accedi con Google
Il sito riceve la mia password Google quando uso Accedi con Google?
No. Con Accedi con Google le credenziali non transitano mai dal server del sito. L’autenticazione avviene presso Google e il sito riceve solo un token ID firmato che dimostra la tua identita’, senza mai vedere password, codici 2FA, passkey o cookie della sessione Google.
Un sito puo’ leggere la mia Gmail solo perche’ ho fatto login con Google?
No. Il login usa gli scope openid email profile, che non permettono l’accesso a Gmail. Per leggere la posta serve lo scope OAuth gmail.readonly (o simili), classificato da Google come restricted, con una schermata di consenso separata che elenca esplicitamente quel permesso.
Il mio numero di telefono viene condiviso con Accedi con Google?
No. Con gli scope standard il numero non viene trasmesso. Servono scope specifici della People API, che tratta separatamente numeri, indirizzi, data di nascita e dati sull’organizzazione, richiedendo un consenso dedicato.
Se revoco Accedi con Google, il sito cancella anche il mio account?
No. Revocare il collegamento impedisce al sito di usare Google per farti accedere, ma non tocca l’account gia’ creato ne’ i dati che il sito ha memorizzato. Per cancellarli devi usare le impostazioni del servizio, spesso dalla sezione profilo o dalla richiesta di eliminazione account.
In sintesi
Accedi con Google e’ progettato per condividere il minimo indispensabile: un ID univoco e qualche dato di profilo, senza mai consegnare la password ne’ aprire porte su Gmail o Drive. Il rischio vero non e’ il pulsante, ma un consenso OAuth firmato distrattamente e un elenco di collegamenti a terze parti mai piu’ controllato. Le stesse buone abitudini valgono anche per altri servizi di identita’, come mostra il caso della registrazione Signal senza numero di telefono o della spinta verso le passkey su Windows 11: meno segreti in giro, piu’ controllo sull’identita’.
Tu quanti servizi hai collegato al tuo account Google negli ultimi anni? Dai un’occhiata a myaccount.google.com/connections e raccontamelo nei commenti.
#tuttelevitediunmaker
tuttelevitediunmaker
Professionista IT | AI & Cybersecurity | Creator YouTube
Lavoro da anni nel mondo delle utility e dell’energia con un focus tecnico su intelligenza artificiale, cybersecurity ed elettronica. Sul canale @tuttelevitediunmaker traduco i temi tech in guide pratiche, e su Patreon pubblico approfondimenti e materiali dedicati.
Scopri di più da TUTTELEVITEDIUNMAKER NEWS
Abbonati per ricevere gli ultimi articoli inviati alla tua e-mail.


Comments 1