Google Sign-In: cos’è, accesso con Google e SDK OAuth 2.0

Cos’è Google Sign-In?

Google Sign-In è un servizio di Single Sign-On (SSO) fornito da Google per l’autenticazione degli utenti in applicazioni di terze parti. L’SDK consente agli sviluppatori di integrare l’accesso tramite un account Google senza dover creare un proprio sistema di registrazione. La tecnologia si basa sul protocollo OAuth 2.0 e OpenID Connect, fornendo informazioni sull’identità dell’utente: nome, email, avatar e identificatore univoco.

A differenza dell’autenticazione tradizionale tramite email e password, Google Sign-In elimina la necessità di ricordare le password e di passare attraverso la procedura di registrazione. L’utente seleziona un account Google sul dispositivo, conferma le autorizzazioni e l’app riceve un token di accesso. Secondo Google Identity Platform (2025), le app con Google Sign-In mostrano il 52% di registrazioni riuscite in più rispetto ai moduli email/password.

Google Sign-In supporta tre scenari di utilizzo: autenticazione dell’utente (ottenimento di ID Token), autorizzazione per l’accesso alle API Google (ottenimento di Access Token) e autenticazione senza interruzioni (Silent Sign-In) per utenti già autorizzati. Ogni scenario richiede un insieme diverso di ambiti (scopes) e restituisce diversi tipi di token.

Come funziona OAuth 2.0 in Google Sign-In

OAuth 2.0 è un protocollo di autorizzazione che consente a un’app di ottenere accesso limitato alle risorse dell’utente senza rivelare le sue credenziali. Nel contesto di Google Sign-In, il protocollo funziona come segue: l’app richiede l’autorizzazione all’utente tramite Google, riceve un codice di autorizzazione temporaneo, lo scambia con token di accesso e utilizza questi token per chiamare le API Google.

La differenza principale di OAuth 2.0 rispetto ai protocolli precedenti è la separazione dei ruoli tra proprietario della risorsa (utente), client (app), server di autorizzazione (Google) e server delle risorse (API Google). L’app non riceve mai la password dell’utente — solo un token che può essere revocato. Google Identity Platform utilizza la specifica OpenID Connect sopra OAuth 2.0, aggiungendo un ID Token standardizzato in formato JWT.

ID Token vs Access Token: differenze

// Esempio di ottenimento di ID Token tramite Credential Manager
val googleIdOption = GoogleIdCredentialOption.Builder()
    .setServerClientId(serverClientId)
    .build()

val credentialManager = CredentialManager.create(this)
val request = GetCredentialRequest.Builder()
    .addCredentialOption(googleIdOption)
    .build()

credentialManager.getCredential(request)
    .addOnSuccessListener { result ->
        val credential = result.credential as GoogleIdCredential
        Log.d("SignIn", credential.idToken)
    }

ID Token (JWT) contiene tre segmenti: un’intestazione con l’algoritmo di firma, un payload con i dati dell’utente (sub, email, name, picture) e una firma per la verifica. La parte server dell’app verifica la firma dell’ID Token utilizzando le chiavi pubbliche di Google ed estrae l’identificatore dell’utente. Questo approccio garantisce che anche se l’app client viene compromessa, un utente malintenzionato non può falsificare il token senza accedere alla chiave privata di Google.

Credential Manager: nuovo metodo di accesso su Android

Credential Manager è una moderna API Android introdotta nel 2023 che combina tutti i metodi di autenticazione (Google Sign-In, accesso tramite password, Passkeys) in un’unica interfaccia utente. A differenza del vecchio GoogleSignInClient, Credential Manager non richiede WebView per l’accesso — utilizza un Bottom Sheet nativo, che accelera l’autenticazione e migliora l’esperienza utente.

Il vantaggio principale di Credential Manager è un’esperienza utente unificata per tutti i tipi di credenziali. L’utente vede una singola finestra di dialogo dove può scegliere: accedi con Google, usa un Passkey o inserisci una password. Lo sviluppatore non deve gestire diversi flussi di autenticazione — Credential Manager astrae l’interazione con Google Sign-In, Smart Lock e Passkeys. Google raccomanda Credential Manager come metodo principale per integrare Google Sign-In per Android 14+.

Migrazione da GoogleSignInClient a Credential Manager

Migrazione da GoogleSignInClient a Credential Manager richiede la modifica della logica client: invece di GoogleSignInOptions, usa GoogleIdCredentialOption e invece di GoogleSignIn.getSignedInAccountFromIntent, gestisci il risultato tramite GetCredentialResponse. La parte server non richiede modifiche poiché l’ID Token mantiene lo stesso formato JWT. Secondo Google I/O 2024, circa il 40% delle app su Google Play sono già migrate a Credential Manager.

Configurare Google Sign-In in un progetto Android

L’integrazione di Google Sign-In in un’app Android inizia con la configurazione del progetto in Google Cloud Console. Il primo passo è creare un Client ID OAuth 2.0 per Android: specificare il nome del pacchetto dell’app e l’impronta del certificato SHA-1. Google utilizza questi dati per verificare che la richiesta di autenticazione provenga dalla tua app e non da un client fittizio.

Dopo aver creato il client in Google Cloud Console, lo sviluppatore aggiunge la dipendenza Credential Manager a build.gradle e configura GoogleIdCredentialOption con serverClientId. Importante: serverClientId è il Client ID dell’applicazione web dello stesso progetto Google Cloud, che il server utilizza per verificare l’ID Token. L’app client non verifica il token — lo riceve solo e lo inoltra al server.

// build.gradle (app) dependencies
implementation("androidx.credentials:credentials:1.5.0")
implementation("androidx.credentials:credentials-play-services-auth:1.5.0")
implementation("com.google.android.libraries.identity.googleid:googleid:1.1.0")

// Richiedi Google Sign-In tramite Credential Manager
suspend fun requestGoogleSignIn(context: Context): String? {
    val credentialManager = CredentialManager.create(context)
    val googleIdOption = GoogleIdCredentialOption.Builder()
        .setServerClientId(BuildConfig.SERVER_CLIENT_ID)
        .setAutoSelectEnabled(true)
        .build()

    val result = credentialManager.getCredential(
        context as Activity,
        GetCredentialRequest.Builder()
            .addCredentialOption(googleIdOption)
            .build()
    )
    return (result.credential as GoogleIdCredential).idToken
}

Dopo aver ricevuto l’ID Token sul client, l’app lo invia al proprio server dove viene eseguita la verifica. Il server verifica la firma JWT utilizzando le chiavi pubbliche di Google (disponibili su https://www.googleapis.com/oauth2/v3/certs), il tempo di scadenza del token (exp) e il valore del campo aud — deve corrispondere a serverClientId. Dopo la verifica, il server crea la propria sessione, ad esempio emettendo un JWT interno o un Session Token.

Google Sign-In su iOS: configurazione e caratteristiche

L’integrazione di Google Sign-In su iOS avviene tramite l’SDK GoogleSignIn-iOS, disponibile tramite CocoaPods o Swift Package Manager. Il processo di configurazione include la creazione di un Client ID per iOS in Google Cloud Console (specificando il Bundle Identifier), l’aggiunta di un URL Scheme per il callback e la configurazione di AppDelegate per gestire l’URL restituito da Google dopo l’autenticazione.

Una differenza importante della versione iOS di Google Sign-In rispetto ad Android è la necessità di configurare URL Scheme e Info.plist. GoogleSDK utilizza Universal Links per il callback, ma per il fallback è richiesto un URL Scheme del tipo `com.googleusercontent.apps.[CLIENT_ID]`. È necessaria anche la configurazione di Keychain Sharing per salvare il refresh token tra gli avvii dell’app. Secondo la documentazione di Google Identity, l’SDK iOS supporta iOS 15 e versioni successive.

// Configurazione di Google Sign-In su iOS
import GoogleSignIn

class SignInManager: ObservableObject {
    func signIn(presenting viewController: UIViewController) {
        GIDSignIn.sharedInstance.signIn(
            withPresenting: viewController
        ) { signInResult, error in
            guard let result = signInResult else {
                print("Sign in failed: \(error)")
                return
            }
            let idToken = result.user.idToken.tokenString
            // Invio ID Token al server
            sendTokenToBackend(idToken)
        }
    }
}

Su iOS, Google Sign-In supporta Silent Sign-In per gli utenti che hanno già autorizzato. Il metodo restorePreviousSignIn ripristina automaticamente la sessione se il refresh token è salvato in Keychain. Questo è particolarmente importante per le app in cui l’utente non deve riaccedere ad ogni avvio. Secondo Google, Silent Sign-In ha successo nell’85% dei casi su dispositivi con sessione Google attiva.

Gestione dei token e sicurezza

Sicurezza di Google Sign-In è costruita su tre livelli: verifica del client (firma SHA-1 dell’app), crittografia del trasporto (HTTPS/TLS) e firma crittografica JWT. L’ID Token ricevuto da Google è firmato utilizzando l’algoritmo RS256 (RSA con SHA-256). La parte server dell’app deve verificare la firma del token, la scadenza e l’emittente (iss) — solo accounts.google.com.

Access Token è un token temporaneo (vive 1 ora) che fornisce accesso alle API Google (Google Drive, Google Calendar, YouTube, ecc.). A differenza dell’ID Token, l’Access Token non contiene informazioni sull’utente — è una stringa opaca che il server API Google utilizza per l’autorizzazione delle richieste. Refresh Token è un token di lunga durata che consente di ottenere nuovi Access Token senza che l’utente riacceda. Il Refresh Token viene emesso solo al primo accesso e può essere revocato dall’utente nelle impostazioni dell’account Google.

// Esempio di elaborazione di ID Token sul server (pseudocodice)
fun verifyGoogleToken(idToken: String): User? {
    val verifier = GoogleIdTokenVerifier.Builder(
        NetHttpTransport(), GsonFactory.getDefaultInstance()
    ).setAudience(listOf(CLIENT_ID))
     .build()

    val token = verifier.verify(idToken) ?: return null
    val payload = token.payload

    return User(
        id = payload.subject,
        email = payload.email,
        name = payload.get("name") as String
    )
}

Refresh Token e gestione della sessione

Raccomandazioni di sicurezza: non trasmettere mai l’ID Token attraverso canali non sicuri, utilizza HTTPS per tutte le richieste al server, verifica la scadenza del token (campo exp) e l’emittente (iss). Sul client, non memorizzare i token in SharedPreferences senza crittografia — utilizza EncryptedSharedPreferences o Android Keystore. Google Sign-In non è progettato per l’autenticazione server-to-server — per questo utilizza Service Accounts.

Esempio di codice: integrazione di Google Sign-In in Kotlin

Un esempio completo di integrazione di Google Sign-In in un’app Android utilizzando Credential Manager e ViewModel. L’app mostra un pulsante di accesso, dopo l’autenticazione invia l’ID Token al server e mostra le informazioni dell’utente. Il codice utilizza le coroutine per il lavoro asincrono con Credential Manager.

class SignInViewModel: ViewModel() {
    private val cm = CredentialManager.create(getApplication())

    private val googleOption = GoogleIdCredentialOption.Builder()
        .setServerClientId(BuildConfig.SERVER_CLIENT_ID)
        .build()

    suspend fun signIn(): SignInResult {
        return try {
            val response = cm.getCredential(
                GetCredentialRequest.Builder()
                    .addCredentialOption(googleOption)
                    .build()
            )
            val credential = response.credential as GoogleIdCredential
            SignInResult.Success(credential.idToken)
        } catch (e: GetCredentialCancellationException) {
            SignInResult.Cancelled
        }
    }
}

sealed class SignInResult {
    data class Success(val idToken: String) : SignInResult()
    data class Error(val message: String) : SignInResult()
    data class Cancelled : SignInResult()
}

Dopo l’autenticazione riuscita, l’app deve inviare l’ID Token al proprio server per la verifica e la creazione della sessione. Si raccomanda di utilizzare HTTPS e di passare il token nel corpo della richiesta POST. Il server restituisce il proprio token di sessione, che il client memorizza in EncryptedSharedPreferences. Ad ogni richiesta successiva al server, viene utilizzato il token interno, non l’ID Token di Google.

Errori comuni di integrazione e soluzioni

Il primo errore comune è la mancata corrispondenza del certificato SHA-1. Google Cloud Console lega il Client ID OAuth 2.0 all’impronta del certificato SHA-1. Se l’app viene compilata con una chiave di debug ma il Client ID è stato creato per una chiave di release, Google Sign-In restituirà l’errore 12501 (SIGN_IN_FAILED). Soluzione: aggiungi entrambe le impronte SHA-1 (debug e release) in Google Cloud Console o utilizza un Client ID per lo sviluppo e uno separato per la produzione.

Il secondo problema frequente è un serverClientId errato. Gli sviluppatori spesso utilizzano il Client ID Android invece del Client ID dell’applicazione web nel parametro serverClientId di Credential Manager. Google richiede esattamente il Client ID web per generare l’ID Token destinato alla verifica del server. Il Client ID Android viene utilizzato solo per identificare l’app durante l’autenticazione. Assicurati che serverClientId corrisponda all’applicazione web in Google Cloud Console.

Il terzo errore è ignorare la gestione dell’annullamento. L’utente può chiudere la finestra di dialogo di Google Sign-In senza completare l’autenticazione. Credential Manager lancia un’eccezione GetCredentialCancellationException che deve essere gestita separatamente dagli altri errori. Molti sviluppatori gestiscono tutte le eccezioni come errori, mostrando all’utente un messaggio di “Accesso fallito” quando l’utente ha semplicemente annullato l’operazione. Gestione corretta: in caso di annullamento — non mostrare nulla, torna semplicemente allo stato iniziale.