Google Sign-In: ce este, autentificare prin Google și OAuth 2.0 SDK

Autor: IT Sectr Publicat: 2026-04-29 Timp de citire: 10 min

Google Sign-In — acesta este un SDK de la Google care realizează autentificarea utilizatorilor prin conturile Google în aplicații mobile și web. La baza tehnologiei stă protocolul OAuth 2.0, care permite obținerea de tokeni de acces la Google API fără transmiterea parolei către aplicația terță. Peste 3 miliarde de dispozitive Android suportă Google Sign-In, ceea ce îl face cea mai răspêndită metodă de autentificare în aplicațiile mobile. Potrivit Google Identity Platform, 2025, integrarea SDK reduce timpul de înregistrare cu 60% și crește conversia utilizatorilor.

Principalele

  • Google Sign-In — SDK de autentificare prin cont Google bazat pe OAuth 2.0
  • OAuth 2.0 — protocol de autorizare în care aplicația primește un token de acces fără parola utilizatorului
  • Credential Manager — API modern Android pentru autentificarea prin Google fără WebView
  • ID Token — JSON Web Token (JWT) care conține datele de identificare ale utilizatorului
  • Multiplatformă — Google Sign-In funcționează pe Android, iOS, web și platforme desktop

Ce este Google Sign-In?

Google Sign-In — este un serviciu de autentificare unică (Single Sign-On) oferit de Google pentru autentificarea utilizatorilor în aplicații terțe. SDK permite dezvoltatorilor să integreze autentificarea prin cont Google fără a crea propriul sistem de înregistrare. Tehnologia se bazează pe protocolul OAuth 2.0 și OpenID Connect, asigurând obținerea informațiilor de identificare ale utilizatorului: nume, email, avatar și un identificator unic.

Spre deosebire de autentificarea tradițională prin email și parolă, Google Sign-In elimină necesitatea de a memora parole și de a trece prin procedura de înregistrare. Utilizatorul selectează un cont Google pe dispozitiv, confirmă permisiunile, iar aplicația primește un token de acces. Potrivit Google Identity Platform (2025), aplicațiile cu Google Sign-In înregistrează cu 52% mai multe înregistrări reușite comparativ cu formularul email/parolă.

Google Sign-In suportă trei scenarii de utilizare: autentificarea utilizatorului (obținerea ID Token), autorizarea accesului la Google API (obținerea Access Token) și autentificarea fără probleme (Silent Sign-In) pentru utilizatorii deja autorizați. Fiecare scenariu necesită un set diferit de permisiuni (scopes) și returnează diferite tipuri de tokeni.

Cum funcționează OAuth 2.0 în Google Sign-In

OAuth 2.0 — este un protocol de autorizare care permite aplicației să obțină acces limitat la resursele utilizatorului fără a dezvălui datele sale de autentificare. În contextul Google Sign-In, protocolul funcționează astfel: aplicația solicită autorizarea de la utilizator prin Google, primește un cod temporar de autorizare, îl schimbă pe tokeni de acces și utilizează acești tokeni pentru a apela Google API.

Diferența cheie a OAuth 2.0 față de protocoalele mai vechi — separarea rolurilor între proprietarul resursei (utilizator), client (aplicație), serverul de autorizare (Google) și serverul de resurse (Google API). Aplicația nu primește niciodată parola utilizatorului — doar un token care poate fi revocat. Google Identity Platform utilizează specificația OpenID Connect peste OAuth 2.0, adăugând un ID Token standardizat în format JWT.

ID Token și Access Token: diferențe

kotlin
// Exemplu de obținere a ID Token prin 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) conține trei segmente: antet cu algoritmul de semnare, payload cu datele utilizatorului (sub, email, name, picture) și semnătura pentru verificare. Partea de server a aplicației verifică semnătura ID Token folosind cheile publice Google și extrage identificatorul utilizatorului. Această abordare garantează că, chiar dacă aplicația client este compromisă, atacatorul nu va putea falsifica tokenul fără acces la cheia privată Google.

Credential Manager: noua metodă de autentificare pe Android

Credential Manager — este un API modern Android, prezentat în 2023, care combină toate metodele de autentificare (Google Sign-In, autentificare prin parolă, Passkeys) într-o singură interfață de utilizator. Spre deosebire de vechiul GoogleSignInClient, Credential Manager nu necesită WebView pentru autentificare — se utilizează un Bottom Sheet nativ, ceea ce accelerează autentificarea și îmbunătățește experiența utilizatorului.

Principalul avantaj al Credential Manager — UX unitar pentru toate tipurile de date de autentificare. Utilizatorul vede un singur dialog în care poate alege: să se autentifice prin Google, să folosească Passkey sau să introducă parola. Dezvoltatorul nu trebuie să gestioneze fluxuri diferite de autentificare — Credential Manager abstractizează interacțiunea cu Google Sign-In, Smart Lock și Passkeys. Google recomandă Credential Manager ca metodă principală de integrare Google Sign-In pentru Android 14+.

ParametruGoogleSignInClient (învechit)Credential Manager
API minimAndroid 4.4 (API 19)Android 4.4 (API 19)
InterfațăWebView / BottomSheetBottom Sheet nativ
Suport PasskeysNuDa
Dimensiune SDK~500 KB~150 KB
StatusDeprecated (2024)Recomandat de Google

Migrarea de la GoogleSignInClient la Credential Manager

Migrarea de la GoogleSignInClient la Credential Manager necesită modificarea logicii client: în loc de GoogleSignInOptions se utilizează GoogleIdCredentialOption, iar în loc de GoogleSignIn.getSignedInAccountFromIntent — gestionarea rezultatului prin GetCredentialResponse. Partea de server nu necesită modificări, deoarece ID Token rămâne în același format JWT. Potrivit Google I/O 2024, aproximativ 40% din aplicațiile din Google Play au trecut deja la Credential Manager.

Configurarea Google Sign-In în proiectul Android

Integrarea Google Sign-In într-o aplicație Android începe cu configurarea proiectului în Google Cloud Console. Primul pas — crearea unui OAuth 2.0 Client ID pentru Android: pentru aceasta se indică package name-ul aplicației și SHA-1 al certificatului de semnare. Google utilizează aceste date pentru a verifica că cererea de autentificare provine într-adevăr din aplicația dvs., nu de la un client fals.

După crearea clientului în Google Cloud Console, dezvoltatorul adaugă dependența Credential Manager în build.gradle și configurează GoogleIdCredentialOption cu serverClientId. Important: serverClientId — este Client ID-ul aplicației web din același proiect Google Cloud, care este utilizat de partea de server pentru verificarea ID Token. Aplicația client nu verifică tokenul — doar îl primește și îl trimite la server.

kotlin
// 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")

// Cerere Google Sign-In prin 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
}

După primirea ID Token pe client, aplicația îl trimite la propriul server pentru verificare și crearea sesiunii. Serverul verifică semnătura JWT folosind cheile publice Google (disponibile la URL-ul https://www.googleapis.com/oauth2/v3/certs), durata de valabilitate a tokenului (exp) și valoarea câmpului aud — trebuie să coincidă cu serverClientId. După verificare, serverul își creează propria sesiune, de exemplu, emite un JWT intern sau un Session Token.

Google Sign-In pe iOS: configurare și caracteristici

Integrarea Google Sign-In pe iOS se realizează prin SDK-ul GoogleSignIn-iOS, disponibil prin CocoaPods sau Swift Package Manager. Procesul de configurare include crearea unui Client ID pentru iOS în Google Cloud Console (cu specificarea Bundle Identifier), adăugarea unei URL Scheme pentru apel invers și configurarea AppDelegate pentru gestionarea URL-ului returnat de Google după autentificare.

O diferență importantă a versiunii iOS de Google Sign-In față de Android — necesitatea configurării URL Scheme și Info.plist. Google SDK utilizează Universal Links pentru apel invers, dar pentru fallback este necesară o URL Scheme de forma `com.googleusercontent.apps.[CLIENT_ID]`. De asemenea, este necesară configurarea Keychain Sharing pentru păstrarea refresh token între lansările aplicației. Potrivit documentației Google Identity, iOS SDK suportă iOS 15 și versiuni ulterioare.

swift
// Configurarea Google Sign-In pe 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
            // Trimiterea ID Token la server
            sendTokenToBackend(idToken)
        }
    }
}

Pe iOS, Google Sign-In suportă Silent Sign-In pentru utilizatorii care s-au autorizat anterior. Metoda restorePreviousSignIn restabilește automat sesiunea dacă refresh token a fost salvat în Keychain. Acest lucru este deosebit de important pentru aplicațiile în care utilizatorul nu trebuie să se autentifice din nou la fiecare lansare. Potrivit Google, Silent Sign-In are succes în 85% din cazuri pe dispozitivele cu o sesiune Google activă.

Gestionarea tokenilor și securitatea

Securitatea Google Sign-In se bazează pe trei niveluri: verificarea clientului (semnătura SHA-1 a aplicației), criptarea transportului (HTTPS/TLS) și semnătura criptografică JWT. ID Token obținut de la Google este semnat folosind algoritmul RS256 (RSA cu SHA-256). Partea de server a aplicației trebuie să verifice semnătura tokenului, durata de valabilitate și issuer-ul (iss) — doar accounts.google.com.

Access Token — este un token temporar (trăiește 1 oră) care oferă acces la Google API (Google Drive, Google Calendar, YouTube etc.). Spre deosebire de ID Token, Access Token nu conține informații despre utilizator — este un șir opac pe care serverul Google API îl folosește pentru autorizarea cererii. Refresh Token — un token de lungă durată care permite obținerea de noi Access Token fără reintrarea utilizatorului. Refresh Token este emis doar la prima autentificare și poate fi revocat de utilizator în setările contului Google.

kotlin
// Exemplu de procesare a ID Token pe server (pseudocod)
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 și gestionarea sesiunii

Recomandări de securitate: nu transmiteți niciodată ID Token prin canale nesecurizate, utilizați HTTPS pentru toate cererile către server, verificați durata de valabilitate a tokenului (câmpul exp) și issuer-ul (iss). Pe client, nu stocați tokenii în SharedPreferences fără criptare — utilizați EncryptedSharedPreferences sau Android Keystore. Google Sign-In nu este destinat autentificării server-server — pentru aceasta se utilizează conturi de serviciu (Service Accounts).

Exemplu de cod: integrarea Google Sign-In în Kotlin

Un exemplu complet de integrare Google Sign-In într-o aplicație Android folosind Credential Manager și ViewModel. Aplicația afișează un buton de autentificare, după autentificare trimite ID Token la server și arată informații despre utilizator. Codul utilizează corutine pentru lucrul asincron cu Credential Manager.

kotlin
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()
}

După autentificarea reușită, aplicația trebuie să trimită ID Token la propriul server pentru verificare și crearea sesiunii. Se recomandă utilizarea HTTPS și transmiterea tokenului în corpul cererii POST. Serverul returnează propriul token de sesiune, pe care clientul îl stochează în EncryptedSharedPreferences. La fiecare cerere ulterioară către server se utilizează tokenul intern, nu ID Token Google.

Greșeli tipice la integrare și soluțiile lor

Prima greșeală frecventă — nepotrivirea SHA-1 a certificatului. Google Cloud Console leagă OAuth 2.0 Client ID de amprenta SHA-1 a certificatului de semnare. Dacă aplicația este construită cu cheia de debug, iar Client ID a fost creat pentru cheia de release, Google Sign-In va returna eroarea 12501 (SIGN_IN_FAILED). Soluție — adăugați ambele SHA-1 (debug și release) în Google Cloud Console sau utilizați un Client ID pentru dezvoltare și unul separat pentru producție.

A doua problemă frecventă — serverClientId incorect. Dezvoltatorii folosesc adesea Client ID Android în loc de Client ID al aplicației web în parametrul serverClientId al Credential Manager. Google necesită exact web-client ID pentru generarea ID Token destinat verificării pe server. Android Client ID este utilizat doar pentru identificarea aplicației în procesul de autentificare. Verificați că serverClientId corespunde aplicației web din Google Cloud Console.

A treia greșeală — ignorarea gestionării anulării. Utilizatorul poate închide dialogul Google Sign-In fără a finaliza autentificarea. Credential Manager aruncă GetCredentialCancellationException, care trebuie gestionat separat de alte erori. Mulți dezvoltatori gestionează toate excepțiile ca erori, afișând utilizatorului mesajul „Autentificare eșuată”, deși utilizatorul a anulat pur și simplu operațiunea. Gestionarea corectă: la Cancelled — nu afișați nimic, reveniți pur și simplu la starea inițială.

Întrebări frecvente

Ce versiune a Google Sign-In SDK să folosesc în 2026?

Se recomandă utilizarea Credential Manager (AndroidX Credentials) pentru Android și GIDSignIn SDK prin Swift Package Manager pentru iOS. Credential Manager — un API modern suportat de Google, care combină Google Sign-In, Passkeys și autentificarea prin parolă într-o singură interfață. GoogleSignInClient învechit (com.google.android.gms:auth) nu mai este recomandat pentru utilizare.

Care este diferența dintre ID Token și Access Token în Google Sign-In?

ID Token — este un JWT care conține informații despre utilizator (nume, email, ID unic). Este utilizat pentru autentificarea pe partea de server a aplicației. Access Token — un șir opac pentru accesul la Google API (Google Drive, Calendar). ID Token trăiește 1 oră, Access Token — de asemenea 1 oră, dar poate fi reîmprospătat prin Refresh Token.

Pot folosi Google Sign-In fără verificare pe server?

Tehnic este posibil, dar nu este sigur. Dacă verificați ID Token doar pe client, un atacator poate decompila aplicația și extrage logica de verificare. Verificarea pe server cu ajutorul cheilor publice Google garantează că tokenul a fost într-adevăr emis de Google și nu este falsificat. Pentru aplicații fără server, utilizați Firebase Authentication.

De ce Google Sign-In returnează eroarea 12501?

Eroarea 12501 (SIGN_IN_FAILED) apare atunci când SHA-1 certificatului aplicației nu corespunde cu cel indicat în Google Cloud Console. Soluție: adăugați SHA-1 de la certificatul de debug (din Android Studio) și de la certificatul de release în consolă. De asemenea, verificați că package name-ul din consolă coincide cu cel din build.gradle. După modificare, poate fi necesară până la 24 de ore pentru propagare.

Suportă Google Sign-In autentificarea fără internet?

Nu, Google Sign-In necesită conexiune la internet pentru a comunica cu serverele Google. Dacă dispozitivul este offline, utilizați mecanismul de memorare a sesiunii: după autentificarea reușită, salvați tokenul în EncryptedSharedPreferences și verificați-i valabilitatea la următoarea lansare. În absența rețelei, afișați datele salvate și propuneți autentificarea mai târziu.

Concluzii

  • Google Sign-In — SDK de autentificare prin cont Google bazat pe OAuth 2.0 și OpenID Connect
  • OAuth 2.0 — protocol în care aplicația primește un token de acces fără transmiterea parolei utilizatorului
  • Credential Manager — API modern Android pentru Google Sign-In cu Bottom Sheet nativ și suport Passkeys
  • ID Token — JWT cu datele utilizatorului pe care serverul îl verifică cu ajutorul cheilor publice Google
  • Securitatea se bazează pe semnătura SHA-1 a aplicației, HTTPS și verificarea criptografică JWT
  • Integrarea iOS necesită configurarea URL Scheme, Keychain Sharing și GoogleSignIn SDK prin Swift Package Manager
  • Greșeli frecvente — nepotrivire SHA-1, serverClientId incorect și ignorarea CancellationException

Vom dezvolta o aplicație mobilă la cheie

IT Sectr creează aplicații iOS și Android pentru startup-uri și afaceri din 2017. Vă vom consilia și vă vom propune cea mai bună soluție.

Discutați proiectul

Citiți și