Google Sign-In: mi ez, bejelentkezés Google-on keresztül és OAuth 2.0 SDK

Mi az a Google Sign-In?

Google Sign-In — egy egyszeri bejelentkezési szolgáltatás (Single Sign-On), amelyet a Google nyújt a felhasználók hitelesítéséhez harmadik fél alkalmazásaiban. Az SDK lehetővé teszi a fejlesztők számára, hogy integrálják a Google-fiókon keresztüli bejelentkezést anélkül, hogy saját regisztrációs rendszert kellene létrehozniuk. A technológia az OAuth 2.0 protokollon és az OpenID Connecten alapul, biztosítva a felhasználó azonosítási adatainak megszerzését: név, e-mail, avatar és egyedi azonosító.

Ellentétben a hagyományos e-mail és jelszó alapú hitelesítéssel, a Google Sign-In kiküszöböli a jelszavak megjegyzésének és a regisztrációs eljáráson való átesés szükségességét. A felhasználó kiválaszt egy Google-fiókot az eszközön, megerősíti az engedélyeket, és az alkalmazás megkapja a hozzáférési tokent. A Google Identity Platform (2025) adatai szerint a Google Sign-In-t használó alkalmazások 52%-kal több sikeres regisztrációt mutatnak az e-mail/jelszó űrlaphoz képest.

A Google Sign-In három használati forgatókönyvet támogat: felhasználói hitelesítés (ID Token megszerzése), hozzáférés engedélyezése a Google API-hoz (Access Token megszerzése) és zökkenőmentes hitelesítés (Silent Sign-In) a már engedélyezett felhasználók számára. Minden forgatókönyv eltérő engedélykészletet (scopes) igényel és különböző típusú tokeneket ad vissza.

Hogyan működik az OAuth 2.0 a Google Sign-In-ben

OAuth 2.0 — egy engedélyezési protokoll, amely lehetővé teszi az alkalmazás számára, hogy korlátozott hozzáférést kapjon a felhasználó erőforrásaihoz anélkül, hogy felfedné a hitelesítési adatait. A Google Sign-In kontextusában a protokoll a következőképpen működik: az alkalmazás engedélyt kér a felhasználótól a Google-on keresztül, kap egy ideiglenes engedélyezési kódot, azt hozzáférési tokenekre váltja, és ezeket a tokeneket használja a Google API meghívására.

Az OAuth 2.0 fő különbsége a korábbi protokollokhoz képest — a szerepkörök elkülönítése az erőforrás tulajdonosa (felhasználó), az ügyfél (alkalmazás), az engedélyezési szerver (Google) és az erőforrás szerver (Google API) között. Az alkalmazás soha nem kapja meg a felhasználó jelszavát — csak egy tokent, amely visszavonható. A Google Identity Platform az OpenID Connect specifikációt használja az OAuth 2.0 tetején, egy szabványosított ID Token-t adva hozzá JWT formátumban.

ID Token és Access Token: különbségek

// Példa ID Token megszerzésére Credential Manager segítségével
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) három szegmenst tartalmaz: fejléc az aláírási algoritmussal, payload a felhasználói adatokkal (sub, email, name, picture) és aláírás az ellenőrzéshez. Az alkalmazás szerveroldali része ellenőrzi az ID Token aláírását a Google nyilvános kulcsainak használatával és kinyeri a felhasználó azonosítóját. Ez a megközelítés garantálja, hogy ha az ügyfélalkalmazás kompromittálódik is, a támadó nem tudja meghamisítani a tokent a Google privát kulcsához való hozzáférés nélkül.

Credential Manager: új bejelentkezési mód Androidon

Credential Manager — egy modern Android API, amelyet 2023-ban mutattak be, és amely az összes hitelesítési módot (Google Sign-In, jelszavas bejelentkezés, Passkeys) egyetlen felhasználói felületben egyesíti. A régi GoogleSignInClient-tel ellentétben a Credential Manager nem igényel WebView-t a bejelentkezéshez — natív Bottom Sheet-et használ, ami gyorsítja a hitelesítést és javítja a felhasználói élményt.

A Credential Manager fő előnye — egységes UX az összes típusú hitelesítési adathoz. A felhasználó egyetlen párbeszédablakot lát, ahol választhat: bejelentkezés Google-on keresztül, Passkey használata vagy jelszó megadása. A fejlesztőnek nem kell különböző hitelesítési folyamatokat kezelnie — a Credential Manager elvonatkoztatja a Google Sign-In, Smart Lock és Passkeys interakcióját. A Google a Credential Manager-t ajánja fő Google Sign-In integrációs módként Android 14+ esetén.

Migráció GoogleSignInClient-ről Credential Manager-re

Migráció a GoogleSignInClient-ről a Credential Manager-re az ügyféllogika megváltoztatását igényli: a GoogleSignInOptions helyett GoogleIdCredentialOption-t használunk, a GoogleSignIn.getSignedInAccountFromIntent helyett pedig az eredmény feldolgozását a GetCredentialResponse-on keresztül. A szerveroldali rész nem igényel változtatást, mert az ID Token ugyanabban a JWT formátumban marad. A Google I/O 2024 adatai szerint a Google Play alkalmazásainak körülbelül 40%-a már áttért a Credential Manager-re.

Google Sign-In beállítása Android projektben

A Google Sign-In integrálása egy Android-alkalmazásba a projekt Google Cloud Console-ban történő beállításával kezdődik. Az első lépés — OAuth 2.0 Client ID létrehozása Androidhoz: ehhez meg kell adni az alkalmazás package name-jét és az aláírási tanúsítvány SHA-1 lenyomatát. A Google ezeket az adatokat használja annak ellenőrzésére, hogy a hitelesítési kérés valóban az Ön alkalmazásából származik, és nem egy hamis ügyféltől.

Az ügyfél létrehozása után a Google Cloud Console-ban a fejlesztő hozzáadja a Credential Manager függőséget a build.gradle-ben és konfigurálja a GoogleIdCredentialOption-t a serverClientId-val. Fontos: a serverClientId — az ugyanabból a Google Cloud projektből származó webalkalmazás Client ID-je, amelyet a szerveroldali rész használ az ID Token ellenőrzéséhez. Az ügyfélalkalmazás nem ellenőrzi a tokent — csak megkapja és továbbítja a szerverre.

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

// Google Sign-In kérés Credential Manageren keresztül
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
}

Miután az ügyfél megkapta az ID Token-t, az alkalmazás elküldi azt a saját szerverére ellenőrzés és munkamenet létrehozása céljából. A szerver ellenőrzi a JWT aláírását a Google nyilvános kulcsainak használatával (elérhető az https://www.googleapis.com/oauth2/v3/certs URL-en), a token érvényességi idejét (exp) és az aud mező értékét — egyeznie kell a serverClientId-val. Az ellenőrzés után a szerver létrehozza a saját munkamenetét, például kiad egy belső JWT-t vagy Session Token-t.

Google Sign-In iOS-en: beállítás és jellemzők

A Google Sign-In integrálása iOS-en a GoogleSignIn-iOS SDK-n keresztül történik, amely a CocoaPods-on vagy a Swift Package Manageren keresztül érhető el. A beállítási folyamat magában foglalja a Client ID létrehozását iOS-hez a Google Cloud Console-ban (a Bundle Identifier megadásával), egy URL Scheme hozzáadását a visszahíváshoz és az AppDelegate konfigurálását a Google által a hitelesítés után visszaküldött URL kezeléséhez.

Az iOS verziójú Google Sign-In fontos különbsége az Androidhoz képest — az URL Scheme és az Info.plist konfigurálásának szükségessége. A Google SDK Universal Links-et használ a visszahíváshoz, de a fallback-hez egy `com.googleusercontent.apps.[CLIENT_ID]` formájú URL Scheme szükséges. A Keychain Sharing konfigurálása is szükséges a refresh token alkalmazásindítások közötti tárolásához. A Google Identity dokumentációja szerint az iOS SDK az iOS 15 és újabb verziókat támogatja.

// Google Sign-In beállítása iOS-en
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
            // ID Token küldése a szerverre
            sendTokenToBackend(idToken)
        }
    }
}

iOS-en a Google Sign-In támogatja a Silent Sign-In-t a korábban engedélyezett felhasználók számára. A restorePreviousSignIn metódus automatikusan visszaállítja a munkamenetet, ha a refresh token el van tárolva a Keychain-ben. Ez különösen fontos az olyan alkalmazásoknál, ahol a felhasználónak nem kell minden indításkor újra bejelentkeznie. A Google adatai szerint a Silent Sign-In az esetek 85%-ban sikeres az aktív Google munkamenettel rendelkező eszközökön.

Tokenek kezelése és biztonság

A Google Sign-In biztonsága három szintre épül: ügyféloldali ellenőrzés (az alkalmazás SHA-1 aláírása), szállítási titkosítás (HTTPS/TLS) és a JWT kriptográfiai aláírása. A Google-től kapott ID Token az RS256 algoritmussal (RSA SHA-256-tal) van aláírva. Az alkalmazás szerveroldali részének ellenőriznie kell a token aláírását, érvényességi idejét és a kibocsátót (iss) — csak accounts.google.com.

Access Token — egy ideiglenes token (1 óra érvényes), amely hozzáférést biztosít a Google API-hoz (Google Drive, Google Calendar, YouTube stb.). Az ID Token-től eltérően az Access Token nem tartalmaz információt a felhasználóról — ez egy opaque karakterlánc, amelyet a Google API szerver használ a kérés engedélyezéséhez. Refresh Token — egy hosszú élettartamú token, amely lehetővé teszi új Access Token beszerzését anélkül, hogy a felhasználónak újra be kellene jelentkeznie. A Refresh Token csak az első bejelentkezéskor kerül kiadásra, és a felhasználó visszavonhatja a Google fiók beállításaiban.

// Példa ID Token feldolgozására a szerveren (pszeudokód)
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 és munkamenet kezelés

Biztonsági ajánlások: soha ne továbbítsa az ID Token-t nem biztonságos csatornákon keresztül, használjon HTTPS-t minden szervernek szóló kéréshez, ellenőrizze a token érvényességi idejét (exp mező) és a kibocsátót (iss). Az ügyfélen ne tárolja a tokeneket SharedPreferences-ben titkosítás nélkül — használjon EncryptedSharedPreferences-t vagy Android Keystore-t. A Google Sign-In nem szerver-szerver hitelesítésre szolgál — ehhez használjon Service Accounts-t.

Kódpélda: Google Sign-In integráció Kotlinban

Teljes példa a Google Sign-In integrálására egy Android-alkalmazásban Credential Manager és ViewModel használatával. Az alkalmazás megjelenít egy bejelentkezési gombot, a hitelesítés után elküldi az ID Token-t a szerverre és megjeleníti a felhasználó információit. A kód korutinokat használ az aszinkron munkavégzéshez a Credential Manager-rel.

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

Sikeres hitelesítés után az alkalmazásnak el kell küldenie az ID Token-t a saját szerverére ellenőrzés és munkamenet létrehozása céljából. Javasolt HTTPS használata és a token POST kérés törzsében történő továbbítása. A szerver visszaadja a saját munkamenet tokenjét, amelyet az ügyfél az EncryptedSharedPreferences-ben tárol. Minden további szervernek szóló kérésnél a belső token kerül felhasználásra, nem a Google ID Token.

Gyakori hibák az integráció során és megoldásuk

Az első gyakori hiba — a tanúsítvány SHA-1 eltérése. A Google Cloud Console az OAuth 2.0 Client ID-t az aláírási tanúsítvány SHA-1 lenyomatához köti. Ha az alkalmazás debug kulccsal van összeállítva, de a Client ID release kulcshoz lett létrehozva, a Google Sign-In 12501 (SIGN_IN_FAILED) hibát ad vissza. Megoldás — adja hozzá mindkét SHA-1-t (debug és release) a Google Cloud Console-ban, vagy használjon egy Client ID-t fejlesztéshez és egy különállót élesítéshez.

A második gyakori probléma — helytelen serverClientId. A fejlesztők gyakran használják az Android Client ID-t a webalkalmazás Client ID-je helyett a Credential Manager serverClientId paraméterében. A Google pontosan a web-client ID-t követeli meg a szerveri ellenőrzésre szánt ID Token előállításához. Az Android Client ID csak az alkalmazás azonosítására szolgál a hitelesítési folyamatban. Ellenőrizze, hogy a serverClientId megegyezik-e a webalkalmazással a Google Cloud Console-ban.

A harmadik hiba — a megszakítás kezelésének figyelmen kívül hagyása. A felhasználó bezárhatja a Google Sign-In párbeszédablakot anélkül, hogy befejezné a hitelesítést. A Credential Manager GetCredentialCancellationException kivételt dob, amelyet külön kell kezelni a más hibáktól. Sok fejlesztő minden kivételt hibaként kezel, és a „Bejelentkezés sikertelen” üzenetet jeleníti meg, pedig a felhasználó egyszerűen megszakította a műveletet. Helyes kezelés: Cancelled esetén — ne jelenítsen meg semmit, egyszerűen térjen vissza a kiinduló állapotba.