In questo articolo Indice dei contenuti 2 sezioni
Il pulsante Accedi con Google compare ormai su una quantità enorme di siti e servizi, e il sospetto che premerlo significhi consegnare mezzo account a uno sconosciuto è più diffuso di quanto si pensi. La realtà, nella stragrande maggioranza dei casi, è molto più contenuta: quel passaggio trasferisce un pacchetto ridotto di informazioni, giusto quelle necessarie a riconoscere la persona e a creare o recuperare il suo profilo sul servizio. Nulla che assomigli a un accesso alla posta o ai documenti personali.
La distinzione che conta davvero è quella tra autenticazione e autorizzazione, due cose che vengono confuse in continuazione. Dire a un sito “sono effettivamente questa persona” non equivale a dargli il permesso di leggere Gmail, frugare in Google Drive o sbirciare nel calendario. Dietro al meccanismo c’è principalmente OpenID Connect, costruito sopra OAuth 2.0, mentre OAuth entra in gioco quando un’applicazione vuole anche ottenere il permesso di usare determinate API di Google.
Cosa viaggia davvero quando si usa Accedi con Google
Quando l’integrazione è fatta come si deve, le credenziali dell’account Google non passano mai dal server del sito. L’autenticazione avviene presso Google e, una volta conclusa, l’applicazione riceve una prova crittografica dell’identità. Il servizio esterno non vede la password, non riceve i codici dell’autenticazione a due fattori, non tocca le passkey memorizzate nell’account e non mette le mani sui cookie della sessione Google. Il senso di tutto l’impianto è proprio questo: evitare che ogni sito debba conservare una nuova password.
Tecnicamente Google consegna un token ID, in genere un JSON Web Token firmato digitalmente. Il server verifica la firma e controlla alcuni valori per accertarsi che il token arrivi davvero da Google e sia destinato proprio a quell’applicazione. Google raccomanda di usare il claim sub come identificatore principale, un valore univoco legato all’account e pensato per riconoscere la stessa persona negli accessi successivi. L’indirizzo email, invece, è un dato di profilo che può cambiare nel tempo, quindi non è una buona chiave tecnica.
Il token può contenere claim come sub, email, email verified, name, given name, family name, picture, hd (il dominio Google Workspace associato), iat ed exp, cioè il momento di generazione e quello di scadenza. La durata documentata si aggira sull’ora, ma non va confusa con la sessione del sito: dopo la verifica, il servizio può creare un proprio cookie di sessione e tenere l’utente collegato secondo regole proprie. Quali claim arrivino dipende dagli scope richiesti, e nel caso tipico sono tre: openid, email e profile. Gli scope stabiliscono quali gruppi di informazioni l’applicazione può chiedere, i claim sono i dati effettivamente restituiti.
Il falso mito dell’accesso automatico a Gmail e Drive
Un token ID serve a dimostrare chi è l’utente. Un access token serve ad accedere a una risorsa o a un’API. Sono due oggetti diversi e il primo non può essere usato per scaricare messaggi di posta o leggere documenti. Per quello servono autorizzazioni OAuth esplicite, con scope dedicati come quelli che Google definisce per gmail.readonly, drive.readonly o calendar.readonly. Un’applicazione che chiede gmail.readonly domanda qualcosa di profondamente diverso rispetto a openid email profile: nel primo caso vuole leggere messaggi e metadati della casella, nel secondo chiede solo i dati per identificare la persona. L’elenco pubblicato da Google mostra quanto granulare sia il sistema, con permessi specifici per Gmail, Drive, Calendar, YouTube, Google Foto e molto altro. Alcuni scope più delicati sono classificati come sensitive o restricted e richiedono verifiche aggiuntive.
Cade anche un’altra convinzione diffusa, quella sul profilo pubblicitario: il token di autenticazione non contiene liste di interessi, fasce di reddito stimate, cronologie di ricerca o annunci visualizzati. Il sito, semmai, può costruirsi un profilo per conto proprio collegando all’account le pagine visitate, gli acquisti e le ricerche interne, ma quei dati li raccoglie lui, non glieli passa Google.
Sul claim email verified vale una precisazione: il valore true indica che Google ha verificato l’indirizzo, e per le caselle gmail.com o per gli account Workspace con claim hd il dato è considerato autorevole. Per un account creato con un indirizzo di un altro provider, invece, la verifica avvenuta in fase di registrazione non garantisce il controllo attuale su quella casella. Quanto al numero di telefono, con openid email profile non viene trasmesso: servono scope specifici della People API, che separa volutamente numeri, indirizzi, data di nascita e dati sull’organizzazione.
Fonte: TecnoAndroid
