Google OAuth e i problemi dell'autenticazione delegata

La cosiddetta “Delegated Authentication” o autenticazione delegata in italiano, è un processo in cui un’applicazione o un servizio Web consente a un’altra applicazione o servizio di autenticare un utente al suo posto. In altre parole, un’applicazione “delega” il processo di autenticazione a un altro soggetto. In un altro articolo abbiamo visto come autenticarsi online via OAuth con Google, Microsoft, Facebook, Apple e altri strumenti che gestiscono servizi di identità.

Google OAuth, così come altri servizi simili, sono frequentemente adoperati per effettuare il login su piattaforme come Zoom, Slack e così via. OAuth è principalmente un protocollo di autorizzazione: consente a un’applicazione di ottenere l’accesso a risorse su un server in nome di un utente, senza dover condividere le credenziali di quello specifico utente.

OIDC (OpenID Connect) è un layer di autenticazione aggiunto a OAuth: fornisce un flusso standardizzato per verificare l’identità dell’utente e definisce il concetto di Token ID, che contiene informazioni sull’identità dell’utente autenticato. La stessa identità digitale SPID si è aperta a OIDC così come altre soluzioni adottate a livello europeo.

Un utente che non lavora più per un’azienda potrebbe sfruttare i problemi dell’autenticazione delegata per continuare ad accedere alle risorse

Un ricercatore indipendente, Dylan Ayrey, ha scoperto una lacuna nella procedura di autenticazione con Google OAuth. A fronte della sua segnalazione, il tecnico afferma di aver ricevuto un premio in denaro di 1.337 dollari dall’azienda di Mountain View.

Quanto messo in evidenza da Ayrey è senza dubbio corretto ma, purtroppo, negli ultimi anni problematiche simili sembrano essere quasi all’ordine del giorno. L’implementazione delle soluzioni di autenticazione mediante OAuth/OIDC dovrebbe quindi essere verificata con la massima attenzione lato server, soprattutto dalle aziende che gestiscono piattaforme SaaS (Software-as-a-Service).

Cerchiamo di riassumere il problema. Ayrey ipotizza il caso di un dipendente che, prima di andarsene dalla sua azienda, crea un account Google non-Gmail del tipo nomeutentereale+stringarandom@nomeazienda.com. L’indirizzo reale, nell’esempio, è nomeutentereale@nomeazienda.com ma tutte le comunicazioni inviate alla prima email (quella con il segno dell’addizione) saranno automaticamente inoltrate a nomeutentereale@nomeazienda.com. Questo meccanismo è comune a molti fornitori del servizio di posta elettronica, non è un “unicum” di Google. Lo abbiamo spiegato anche nell’articolo dedicato a come creare più indirizzi email su Gmail.

Ora, anche se l’azienda usasse Google Workspace, l’utente potrebbe creare un nuovo account nomeutentereale+stringarandom@nomeazienda.com senza associarvi un account Gmail e assumerne il controllo.

Effettuando la procedura di autenticazione via OAuth con tale indirizzo, l’utente potrebbe accedere alle piattaforme Zoom, Slack e così via usate dalla sua ex azienda. Peraltro senza che il suo accesso venga segnalato agli amministratori.

Massima attenzione alla configurazione dell’autenticazione OAuth lato server

Al di là dei casi particolari, ciò che bisognerebbe fare è evitare sempre di autorizzare accessi limitandosi a un semplice controllo sul nome a dominio dell’utente che tenta il login. E, purtroppo, questo avviene molto più di frequente rispetto a quanto possiate lontanamente immaginare.

L’amministratore non dovrebbe perciò concedere mai all’utente privilegi speciali in base al dominio di posta elettronica da questi usato e inviare sempre un’email di conferma all’interno della propria infrastruttura, prima di contrassegnare l’indirizzo come “verificato”. Tutti i principali fornitori di servizi di autenticazione OAuth hanno aggiornato i rispettivi documenti di supporto per rendere esplicito questo concetto. D’altra parte, Google stessa scrive nella pagina dedicata a OpenID Connect: “email: (…) you should not use this value as the primary identifier to link to your user record“. Più chiaro di così…

A Google, comunque, Ayrey consiglia semplicemente di vietare la creazione di nuovi account utente che utilizzino i domini associati ad organizzazioni Google esistenti o comunque di negare la possibilità di registrare account con il simbolo “+” nel nome.