Google Sign-In: ano ito, pag-login sa pamamagitan ng Google at OAuth 2.0 SDK

Ano ang Google Sign-In?

Google Sign-In — ay isang serbisyo ng single sign-on na ibinigay ng Google para sa pag-authenticate ng mga user sa mga third-party na application. Ang SDK ay nagpapahintulot sa mga developer na isama ang pag-login sa pamamagitan ng Google account nang hindi kinakailangang gumawa ng sariling registration system. Ang teknolohiya ay nakabatay sa OAuth 2.0 protocol at OpenID Connect, na nagbibigay ng pagkuha ng identification data ng user: pangalan, email, avatar at natatanging identifier.

Hindi tulad ng tradisyonal na pag-authenticate sa pamamagitan ng email at password, inaalis ng Google Sign-In ang pangangailangan na tandaan ang mga password at dumaan sa proseso ng pagpaparehistro. Pinipili ng user ang Google account sa device, kinukumpirma ang mga pahintulot, at ang app ay tumatanggap ng access token. Ayon sa Google Identity Platform (2025), ang mga app na may Google Sign-In ay nagpapakita ng 52% mas maraming matagumpay na pagpaparehistro kumpara sa form ng email/password.

Sinusuportahan ng Google Sign-In ang tatlong senaryo ng paggamit: pag-authenticate ng user (pagkuha ng ID Token), awtorisasyon ng access sa Google API (pagkuha ng Access Token) at seamless authentication (Silent Sign-In) para sa mga naka-authorize nang user. Ang bawat senaryo ay nangangailangan ng iba't ibang set ng mga pahintulot (scopes) at nagbabalik ng iba't ibang uri ng token.

Paano gumagana ang OAuth 2.0 sa Google Sign-In

OAuth 2.0 — ay isang protocol ng awtorisasyon na nagpapahintulot sa app na makakuha ng limitadong access sa mga resources ng user nang hindi isiniwalat ang kanyang credentials. Sa konteksto ng Google Sign-In, gumagana ang protocol tulad ng sumusunod: ang app ay humihingi ng awtorisasyon mula sa user sa pamamagitan ng Google, tumatanggap ng pansamantalang authorization code, ipinagpapalit ito para sa access tokens at ginagamit ang mga token na ito para tumawag sa Google API.

Ang pangunahing pagkakaiba ng OAuth 2.0 mula sa mas lumang mga protocol — ang paghihiwalay ng mga tungkulin sa pagitan ng may-ari ng resource (user), client (app), authorization server (Google) at resource server (Google API). Ang app ay hindi kailanman tumatanggap ng password ng user — tanging token na maaaring bawiin. Gumagamit ang Google Identity Platform ng OpenID Connect specification sa ibabaw ng OAuth 2.0, nagdaragdag ng standardized na ID Token sa JWT format.

ID Token at Access Token: mga pagkakaiba

// Halimbawa ng pagkuha ng ID Token sa pamamagitan ng 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) ay naglalaman ng tatlong segment: header na may algorithm ng lagda, payload na may data ng user (sub, email, name, picture) at lagda para sa pag-verify. Ang server-side na bahagi ng app ay nagve-verify ng lagda ng ID Token gamit ang mga pampublikong susi ng Google at kinukuha ang identifier ng user. Ginagarantiyahan ng approach na ito na kahit na ang client app ay nakompromiso, hindi magagawa ng attacker na pekein ang token nang walang access sa pribadong susi ng Google.

Credential Manager: bagong paraan ng pag-login sa Android

Credential Manager — ay isang modernong Android API, na ipinakilala noong 2023, na pinagsasama ang lahat ng paraan ng pag-authenticate (Google Sign-In, pag-login gamit ang password, Passkeys) sa iisang user interface. Hindi tulad ng lumang GoogleSignInClient, ang Credential Manager ay hindi nangangailangan ng WebView para sa pag-login — gumagamit ito ng native na Bottom Sheet, na nagpapabilis ng pag-authenticate at nagpapabuti ng karanasan ng user.

Ang pangunahing bentahe ng Credential Manager — pare-parehong UX para sa lahat ng uri ng credentials. Ang user ay nakakakita ng isang dialog box kung saan maaari silang pumili: mag-login sa pamamagitan ng Google, gumamit ng Passkey o magpasok ng password. Ang developer ay hindi kailangang mamahala ng iba't ibang daloy ng pag-authenticate — ang Credential Manager ay nag-aabstrak ng interaksyon sa Google Sign-In, Smart Lock at Passkeys. Inirerekomenda ng Google ang Credential Manager bilang pangunahing paraan ng pagsasama ng Google Sign-In para sa Android 14+.

Paglipat mula GoogleSignInClient patungong Credential Manager

Paglipat mula GoogleSignInClient patungong Credential Manager ay nangangailangan ng pagbabago sa client logic: sa halip na GoogleSignInOptions ay ginagamit ang GoogleIdCredentialOption, at sa halip na GoogleSignIn.getSignedInAccountFromIntent — pag-handle ng resulta sa pamamagitan ng GetCredentialResponse. Ang server-side na bahagi ay hindi nangangailangan ng pagbabago dahil ang ID Token ay nananatili sa parehong JWT format. Ayon sa Google I/O 2024, humigit-kumulang 40% ng mga app sa Google Play ay lumipat na sa Credential Manager.

Pag-configure ng Google Sign-In sa Android project

Ang pagsasama ng Google Sign-In sa Android app ay nagsisimula sa pag-configure ng project sa Google Cloud Console. Ang unang hakbang — paggawa ng OAuth 2.0 Client ID para sa Android: para dito, tinutukoy ang package name ng app at SHA-1 ng signing certificate. Ginagamit ng Google ang data na ito para i-verify na ang authentication request ay nagmumula sa iyong app, hindi mula sa isang pekeng client.

Pagkatapos gumawa ng client sa Google Cloud Console, idinadagdag ng developer ang Credential Manager dependency sa build.gradle at ini-configure ang GoogleIdCredentialOption gamit ang serverClientId. Mahalaga: ang serverClientId — ay ang Client ID ng web app mula sa parehong Google Cloud project, na ginagamit ng server-side na bahagi para sa pag-verify ng ID Token. Ang client app ay hindi nagve-verify ng token — ito ay tumatanggap lamang at ipinapasa ito sa 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")

// Kahilingan ng Google Sign-In sa pamamagitan ng 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
}

Pagkatapos makatanggap ng ID Token sa client, ipinapadala ng app ito sa sarili nitong server para sa pag-verify at paggawa ng session. Inve-verify ng server ang JWT signature gamit ang mga pampublikong susi ng Google (available sa URL https://www.googleapis.com/oauth2/v3/certs), ang validity period ng token (exp) at ang value ng aud field — dapat tumugma sa serverClientId. Pagkatapos ng pag-verify, ang server ay gumagawa ng sarili nitong session, halimbawa, naglalabas ng internal na JWT o Session Token.

Google Sign-In sa iOS: configuration at mga feature

Ang pagsasama ng Google Sign-In sa iOS ay ginagawa sa pamamagitan ng GoogleSignIn-iOS SDK, na available sa pamamagitan ng CocoaPods o Swift Package Manager. Ang proseso ng configuration ay kinabibilangan ng paggawa ng Client ID para sa iOS sa Google Cloud Console (na may pagtukoy ng Bundle Identifier), pagdagdag ng URL Scheme para sa callback at pag-configure ng AppDelegate para sa pag-handle ng URL na ibinabalik ng Google pagkatapos ng authentication.

Isang mahalagang pagkakaiba ng iOS na bersyon ng Google Sign-In mula sa Android — ang pangangailangan na i-configure ang URL Scheme at Info.plist. Gumagamit ang Google SDK ng Universal Links para sa callback, ngunit para sa fallback ay kinakailangan ang URL Scheme na may anyong `com.googleusercontent.apps.[CLIENT_ID]`. Kailangan din ang configuration ng Keychain Sharing para sa pag-imbak ng refresh token sa pagitan ng mga paglunsad ng app. Ayon sa dokumentasyon ng Google Identity, ang iOS SDK ay sumusuporta sa iOS 15 at mas bago.

// Pag-configure ng Google Sign-In sa 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
            // Pagpapadala ng ID Token sa server
            sendTokenToBackend(idToken)
        }
    }
}

Sa iOS, ang Google Sign-In ay sumusuporta sa Silent Sign-In para sa mga user na dati nang naka-authorize. Ang paraang restorePreviousSignIn ay awtomatikong nagre-restore ng session kung ang refresh token ay naka-imbak sa Keychain. Ito ay lalong mahalaga para sa mga app kung saan ang user ay hindi dapat mag-login muli sa bawat paglunsad. Ayon sa Google, ang Silent Sign-In ay matagumpay sa 85% ng mga kaso sa mga device na may aktibong Google session.

Pamamahala ng token at seguridad

Seguridad ng Google Sign-In ay binuo sa tatlong antas: client verification (SHA-1 signature ng app), transport encryption (HTTPS/TLS) at cryptographic signing ng JWT. Ang ID Token na natanggap mula sa Google ay nilagdaan gamit ang RS256 algorithm (RSA na may SHA-256). Ang server-side na bahagi ng app ay dapat mag-verify ng signature ng token, validity period at issuer (iss) — tanging accounts.google.com.

Ang Access Token — ay isang pansamantalang token (1 oras ang bisa) na nagbibigay ng access sa Google API (Google Drive, Google Calendar, YouTube atbp.). Hindi tulad ng ID Token, ang Access Token ay hindi naglalaman ng impormasyon tungkol sa user — ito ay isang opaque string na ginagamit ng Google API server para sa pag-authorize ng request. Refresh Token — isang matagalang token na nagbibigay-daan sa pagkuha ng bagong Access Token nang hindi kailangang mag-login muli ng user. Ang Refresh Token ay ibinibigay lamang sa unang pag-login at maaaring bawiin ng user sa mga setting ng Google account.

// Halimbawa ng pagproseso ng ID Token sa server (pseudocode)
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 at pamamahala ng session

Mga rekomendasyon sa seguridad: huwag kailanman ipadala ang ID Token sa pamamagitan ng hindi secure na mga channel, gumamit ng HTTPS para sa lahat ng request sa server, suriin ang validity period ng token (exp field) at issuer (iss). Sa client, huwag mag-imbak ng mga token sa SharedPreferences nang walang encryption — gumamit ng EncryptedSharedPreferences o Android Keystore. Ang Google Sign-In ay hindi dinisenyo para sa server-to-server authentication — para dito, gumamit ng Service Accounts.

Halimbawa ng code: pagsasama ng Google Sign-In sa Kotlin

Buong halimbawa ng pagsasama ng Google Sign-In sa Android app gamit ang Credential Manager at ViewModel. Ang app ay nagpapakita ng login button, pagkatapos ng authentication ay nagpapadala ng ID Token sa server at nagpapakita ng impormasyon tungkol sa user. Ang code ay gumagamit ng coroutines para sa asynchronous na trabaho sa 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()
}

Pagkatapos ng matagumpay na authentication, ang app ay dapat magpadala ng ID Token sa sarili nitong server para sa pag-verify at paggawa ng session. Inirerekomenda ang paggamit ng HTTPS at pagpapadala ng token sa body ng POST request. Ang server ay nagbabalik ng sarili nitong session token, na iniimbak ng client sa EncryptedSharedPreferences. Sa bawat kasunod na request sa server, ginagamit ang internal na token, hindi ang Google ID Token.

Mga karaniwang pagkakamali sa pagsasama at kanilang solusyon

Ang unang karaniwang pagkakamali — hindi pagtutugma ng SHA-1 ng certificate. Ang Google Cloud Console ay nagbibigkis ng OAuth 2.0 Client ID sa SHA-1 fingerprint ng signing certificate. Kung ang app ay binuo gamit ang debug key, ngunit ang Client ID ay ginawa para sa release key, ang Google Sign-In ay magbabalik ng error 12501 (SIGN_IN_FAILED). Solusyon — idagdag ang parehong SHA-1 (debug at release) sa Google Cloud Console o gumamit ng isang Client ID para sa development at hiwalay para sa production.

Ang pangalawang karaniwang problema — maling serverClientId. Madalas ginagamit ng mga developer ang Android Client ID sa halip na Client ID ng web app sa parameter na serverClientId ng Credential Manager. Ang Google ay nangangailangan ng eksaktong web-client ID para sa pag-generate ng ID Token na nakalaan para sa server verification. Ang Android Client ID ay ginagamit lamang para sa identification ng app sa proseso ng authentication. Suriin kung ang serverClientId ay tumutugma sa web app sa Google Cloud Console.

Ang pangatlong pagkakamali — pagbalewala sa pag-handle ng pagkansela. Maaaring isara ng user ang dialog ng Google Sign-In nang hindi tinatapos ang authentication. Ang Credential Manager ay nagta-throw ng GetCredentialCancellationException na kailangang i-handle nang hiwalay mula sa iba pang mga error. Maraming developer ang nagha-handle ng lahat ng exceptions bilang mga error, na nagpapakita sa user ng mensaheng “Nag-fail ang pag-login”, kahit na kinansela lang ng user ang operasyon. Tamang pag-handle: sa Cancelled — huwag magpakita ng anuman, bumalik lamang sa orihinal na estado.