Google Sign-In: What It Is, Google Login, and OAuth 2.0 SDK

What is Google Sign-In?

Google Sign-In is a Single Sign-On service provided by Google for user authentication in third-party applications. The SDK allows developers to integrate login through a Google account without having to create their own registration system. The technology is based on the OAuth 2.0 protocol and OpenID Connect, providing user identity information: name, email, avatar, and unique identifier.

Unlike traditional email and password authentication, Google Sign-In eliminates the need to remember passwords and go through the registration procedure. The user selects a Google account on the device, confirms permissions, and the app receives an access token. According to Google Identity Platform (2025), apps with Google Sign-In show 52% more successful registrations compared to email/password forms.

Google Sign-In supports three usage scenarios: user authentication (getting ID Token), authorization for access to Google APIs (getting Access Token), and seamless authentication (Silent Sign-In) for already authorized users. Each scenario requires a different set of scopes and returns different types of tokens.

How OAuth 2.0 Works in Google Sign-In

OAuth 2.0 is an authorization protocol that allows an app to get limited access to user resources without disclosing their credentials. In the context of Google Sign-In, the protocol works as follows: the app requests authorization from the user through Google, receives a temporary authorization code, exchanges it for access tokens, and uses those tokens to call Google APIs.

The key difference of OAuth 2.0 from earlier protocols is the separation of roles between the resource owner (user), the client (app), the authorization server (Google) and the resource server (Google API). The app never receives the user’s password — only a token that can be revoked. Google Identity Platform uses the OpenID Connect specification on top of OAuth 2.0, adding a standardized ID Token in JWT format.

ID Token vs Access Token: Differences

// Example of getting ID Token via 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) contains three segments: a header with the signing algorithm, a payload with user data (sub, email, name, picture), and a signature for verification. The server-side part of the app verifies the ID Token signature using Google’s public keys and extracts the user identifier. This approach guarantees that even if the client app is compromised, an attacker cannot forge the token without access to Google’s private key.

Credential Manager: New Login Method on Android

Credential Manager is a modern Android API introduced in 2023 that combines all authentication methods (Google Sign-In, password login, Passkeys) into a single user interface. Unlike the old GoogleSignInClient, Credential Manager does not require a WebView for login — it uses a native Bottom Sheet, which speeds up authentication and improves user experience.

The main advantage of Credential Manager is a unified UX for all credential types. The user sees one dialog where they can choose: sign in with Google, use a Passkey, or enter a password. The developer doesn’t need to manage different authentication flows — Credential Manager abstracts interaction with Google Sign-In, Smart Lock, and Passkeys. Google recommends Credential Manager as the primary way to integrate Google Sign-In for Android 14+.

Migrating from GoogleSignInClient to Credential Manager

Migration from GoogleSignInClient to Credential Manager requires changing client-side logic: instead of GoogleSignInOptions, use GoogleIdCredentialOption, and instead of GoogleSignIn.getSignedInAccountFromIntent, handle the result through GetCredentialResponse. The server-side part does not require changes since the ID Token remains the same JWT format. According to Google I/O 2024, about 40% of apps on Google Play have already migrated to Credential Manager.

Setting up Google Sign-In in Android Project

Integrating Google Sign-In in an Android app starts with configuring the project in Google Cloud Console. The first step is creating an OAuth 2.0 Client ID for Android: specify the app’s package name and SHA-1 certificate fingerprint. Google uses this data to verify that the authentication request comes from your app and not a fake client.

After creating the client in Google Cloud Console, the developer adds the Credential Manager dependency to build.gradle and configures GoogleIdCredentialOption with serverClientId. Important: serverClientId is the Web application Client ID from the same Google Cloud project, which the server side uses to verify the ID Token. The client app does not verify the token — it only receives it and forwards it to the 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")

// Request Google Sign-In via 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
}

After receiving the ID Token on the client, the app sends it to its server where verification is performed. The server verifies the JWT signature using Google’s public keys (available at https://www.googleapis.com/oauth2/v3/certs), the token expiration time (exp), and the aud field value — it must match the serverClientId. After verification, the server creates its own session, for example, issuing an internal JWT or Session Token.

Google Sign-In on iOS: Setup and Features

Integrating Google Sign-In on iOS is done through the GoogleSignIn-iOS SDK, available via CocoaPods or Swift Package Manager. The setup process includes creating a Client ID for iOS in Google Cloud Console (specifying the Bundle Identifier), adding a URL Scheme for callback, and configuring AppDelegate to handle the URL returned by Google after authentication.

An important difference of the iOS version of Google Sign-In from Android is the need to configure URL Scheme and Info.plist. GoogleSDK uses Universal Links for callback, but for fallback, a URL Scheme of the form `com.googleusercontent.apps.[CLIENT_ID]` is required. Keychain Sharing configuration is also needed to save the refresh token between app launches. According to Google Identity documentation, the iOS SDK supports iOS 15 and above.

// Setting up Google Sign-In on 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
            // Sending ID Token to the server
            sendTokenToBackend(idToken)
        }
    }
}

On iOS, Google Sign-In supports Silent Sign-In for users who have previously authorized. The restorePreviousSignIn method automatically restores the session if the refresh token is saved in Keychain. This is especially important for apps where the user should not re-enter at every launch. According to Google, Silent Sign-In is successful in 85% of cases on devices with an active Google session.

Token Handling and Security

Security of Google Sign-In is built on three levels: client verification (SHA-1 app signature), transport encryption (HTTPS/TLS), and cryptographic JWT signature. The ID Token received from Google is signed using the RS256 algorithm (RSA with SHA-256). The server-side part of the app must verify the token signature, expiration, and issuer (iss) — only accounts.google.com.

Access Token is a temporary token (lives 1 hour) that provides access to Google APIs (Google Drive, Google Calendar, YouTube, etc.). Unlike the ID Token, the Access Token does not contain user information — it is an opaque string that the Google API server uses for request authorization. Refresh Token is a long-lived token that allows obtaining new Access Tokens without the user re-entering. The Refresh Token is issued only on the first login and can be revoked by the user in their Google account settings.

// Example of processing ID Token on the 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 and Session Management

Security recommendations: never transmit the ID Token over unsecured channels, use HTTPS for all server requests, check the token expiration (exp field) and issuer (iss). On the client, do not store tokens in SharedPreferences without encryption — use EncryptedSharedPreferences or Android Keystore. Google Sign-In is not intended for server-to-server authentication — use Service Accounts for that.

Code Example: Google Sign-In Integration in Kotlin

A complete example of integrating Google Sign-In in an Android app using Credential Manager and ViewModel. The app displays a sign-in button, after authentication sends the ID Token to the server, and shows user information. The code uses coroutines for asynchronous work with 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()
}

After successful authentication, the app should send the ID Token to its server for verification and session creation. It is recommended to use HTTPS and pass the token in the POST request body. The server returns its own session token, which the client stores in EncryptedSharedPreferences. On each subsequent request to the server, the internal token is used, not the Google ID Token.

Common Integration Mistakes and Solutions

The first common mistake is SHA-1 certificate mismatch. Google Cloud Console binds the OAuth 2.0 Client ID to the SHA-1 certificate fingerprint. If the app is built with a debug key but the Client ID was created for a release key, Google Sign-In will return error 12501 (SIGN_IN_FAILED). Solution: add both SHA-1 fingerprints (debug and release) to Google Cloud Console or use one Client ID for development and a separate one for production.

The second frequent problem is an incorrect serverClientId. Developers often use the Android Client ID instead of the Web application Client ID in the serverClientId parameter of Credential Manager. Google requires exactly the web client ID for generating the ID Token intended for server verification. The Android Client ID is used only for identifying the app during authentication. Make sure serverClientId matches the web application in Google Cloud Console.

The third mistake is ignoring cancellation handling. The user may close the Google Sign-In dialog without completing authentication. Credential Manager throws a GetCredentialCancellationException which needs to be handled separately from other errors. Many developers handle all exceptions as errors, showing the user a “Login failed” message when the user simply canceled the operation. Correct handling: on Cancelled — show nothing, just return to the initial state.