Google Sign-In: какво е това, влизане чрез Google и OAuth 2.0 SDK

Какво е Google Sign-In?

Google Sign-In е услуга за единно влизане (Single Sign-On), предоставяна от Google за удостоверяване на потребители в третостранни приложения. SDK позволява на разработчиците да интегрират влизане чрез акаунт в Google, без да се налага да създават собствена система за регистрация. Технологията се основава на протокола OAuth 2.0 и OpenID Connect, осигурявайки получаването на идентификационна информация за потребителя: име, имейл, аватар и уникален идентификатор.

За разлика от традиционното удостоверяване по имейл и парола, Google Sign-In премахва необходимостта от запомняне на пароли и преминаване през процедурата за регистрация. Потребителят избира акаунт в Google на устройството, потвърждава разрешенията, и приложението получава токен за достъп. Според Google Identity Platform (2025) приложенията с Google Sign-In показват 52% повече успешни регистрации в сравнение с формуляра имейл/парола.

Google Sign-In поддържа три сценария на употреба: удостоверяване на потребителя (получаване на ID Token), оторизация за достъп до Google API (получаване на Access Token) и безпроблемно удостоверяване (Silent Sign-In) за вече оторизирани потребители. Всеки сценарий изисква различен набор от разрешения (scopes) и връща различни видове токени.

Как работи OAuth 2.0 в Google Sign-In

OAuth 2.0 е протокол за оторизация, който позволява на приложението да получи ограничен достъп до ресурсите на потребителя, без да разкрива неговите идентификационни данни. В контекста на Google Sign-In протоколът работи по следния начин: приложението изисква оторизация от потребителя чрез Google, получава временен код за оторизация, обменя го за токени за достъп и използва тези токени за извикване на Google API.

Ключовата разлика между OAuth 2.0 и по-ранните протоколи е разделението на ролите между собственика на ресурса (потребителя), клиента (приложението), сървъра за оторизация (Google) и сървъра на ресурсите (Google API). Приложението никога не получава паролата на потребителя — само токен, който може да бъде оттеглен. Google Identity Platform използва спецификацията OpenID Connect върху OAuth 2.0, добавяйки стандартизиран ID Token във формат JWT.

ID Token и Access Token: разлики

// Пример за получаване на ID Token чрез 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("Вход", credential.idToken)
    }

ID Token (JWT) съдържа три сегмента: заглавна част с алгоритъма за подписване, payload с данните на потребителя (sub, email, name, picture) и подпис за верификация. Сървърната част на приложението проверява подписа на ID Token, използвайки публичните ключове на Google, и извлича идентификатора на потребителя. Този подход гарантира, че дори ако клиентското приложение е компрометирано, нападателят няма да може да фалшифицира токена без достъп до частния ключ на Google.

Credential Manager: новият начин за влизане на Android

Credential Manager е съвременен API за Android, представен през 2023 г., който обединява всички начини за удостоверяване (Google Sign-In, влизане с парола, Passkeys) в единен потребителски интерфейс. За разлика от стария GoogleSignInClient, Credential Manager не изисква WebView за влизане — използва се нативен Bottom Sheet, което ускорява удостоверяването и подобрява потребителското изживяване.

Основното предимство на Credential Manager е единният UX за всички видове идентификационни данни. Потребителят вижда един диалогов прозорец, в който може да избере: влизане чрез Google, използване на Passkey или въвеждане на парола. Разработчикът не трябва да управлява различни потоци за удостоверяване — Credential Manager абстрахира взаимодействието с Google Sign-In, Smart Lock и Passkeys. Google препоръчва Credential Manager като основен начин за интеграция на Google Sign-In за Android 14+.

Миграция от GoogleSignInClient към Credential Manager

Миграцията от GoogleSignInClient към Credential Manager изисква промени в клиентската логика: вместо GoogleSignInOptions се използва GoogleIdCredentialOption, а вместо GoogleSignIn.getSignedInAccountFromIntent — обработка на резултата чрез GetCredentialResponse. Сървърната част не изисква промени, тъй като ID Token остава в същия формат JWT. Според Google I/O 2024 около 40% от приложенията в Google Play вече са преминали към Credential Manager.

Настройка на Google Sign-In в Android проект

Интеграцията на Google Sign-In в Android приложение започва с настройката на проекта в Google Cloud Console. Първата стъпка е създаването на OAuth 2.0 Client ID за Android: за целта се посочват package name на приложението и SHA-1 на сертификата за подписване. Google използва тези данни, за да провери, че заявката за удостоверяване идва именно от вашето приложение, а не от фалшив клиент.

След създаването на клиента в Google Cloud Console разработчикът добавя зависимостта на Credential Manager в build.gradle и конфигурира GoogleIdCredentialOption с serverClientId. Важно: serverClientId е Client ID на уеб приложението от същия проект в Google Cloud, който сървърната част използва за верификация на ID Token. Клиентското приложение не проверява токена — то само го получава и го предава на сървъра.

// build.gradle (app) зависимости
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 чрез 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
}

След получаване на ID Token на клиента, приложението го изпраща на собствения си сървър, където се извършва верификацията. Сървърът проверява подписа на JWT с помощта на публичните ключове на Google (достъпни на адрес https://www.googleapis.com/oauth2/v3/certs), срока на валидност на токена (exp) и стойността на полето aud — тя трябва да съвпада със serverClientId. След верификацията сървърът създава собствена сесия, например издава вътрешен JWT или Session Token.

Google Sign-In на iOS: настройка и особености

Интеграцията на Google Sign-In на iOS се извършва чрез SDK GoogleSignIn-iOS, достъпен чрез CocoaPods или Swift Package Manager. Процесът на настройка включва създаването на Client ID за iOS в Google Cloud Console (с посочване на Bundle Identifier), добавяне на URL Scheme за обратно извикване и конфигуриране на AppDelegate за обработка на URL адреса, върнат от Google след удостоверяване.

Важна разлика между iOS версията на Google Sign-In и Android е необходимостта от конфигуриране на URL Scheme и Info.plist. GoogleSDK използва универсални връзки (Universal Links) за обратно извикване, но за fallback се изисква URL Scheme от вида `com.googleusercontent.apps.[CLIENT_ID]`. Също така е необходима настройка на Keychain Sharing за запазване на refresh token между стартиранията на приложението. Според документацията на Google Identity, iOS SDK поддържа iOS 15 и по-нови версии.

// Настройка на Google Sign-In на 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("Влизането не бе успешно: \(error)")
                return
            }
            let idToken = result.user.idToken.tokenString
            // Изпращане на ID Token към сървъра
            sendTokenToBackend(idToken)
        }
    }
}

На iOS Google Sign-In поддържа Silent Sign-In за потребители, които вече са се оторизирали. Методът restorePreviousSignIn автоматично възстановява сесията, ако refresh token е запазен в Keychain. Това е особено важно за приложения, в които потребителят не трябва да влиза отново при всяко стартиране. Според Google Silent Sign-In е успешен в 85% от случаите на устройства с активна сесия в Google.

Обработка на токени и сигурност

Сигурността на Google Sign-In се изгражда на три нива: клиентска верификация (SHA-1 подпис на приложението), транспортно криптиране (HTTPS/TLS) и криптографски подпис на JWT. ID Token, получен от Google, е подписан с алгоритъма RS256 (RSA със SHA-256). Сървърната част на приложението трябва да проверява подписа на токена, срока на валидност и issuer (iss) — само accounts.google.com.

Access Token е временен токен (живее 1 час), който дава достъп до Google API (Google Drive, Google Calendar, YouTube и т.н.). За разлика от ID Token, Access Token не съдържа информация за потребителя — това е opaque-низ, който сървърът на Google API използва за оторизация на заявката. Refresh Token е дълготраен токен, който позволява получаването на нови Access Token без повторно влизане на потребителя. Refresh Token се издава само при първото влизане и може да бъде оттеглен от потребителя в настройките на акаунта в Google.

// Пример за обработка на ID Token на сървъра (псевдокод)
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 и управление на сесията

Препоръки за сигурност: никога не предавайте ID Token през незащитени канали, използвайте HTTPS за всички заявки към сървъра, проверявайте срока на валидност на токена (полето exp) и issuer (iss). На клиента не съхранявайте токени в SharedPreferences без криптиране — използвайте EncryptedSharedPreferences или Android Keystore. Google Sign-In не е предназначен за удостоверяване сървър-сървър — за това се използват сервизни акаунти (Service Accounts).

Примерен код: интеграция на Google Sign-In в Kotlin

Пълен пример за интеграция на Google Sign-In в Android приложение с използване на Credential Manager и ViewModel. Приложението показва бутон за влизане, след удостоверяване изпраща ID Token на сървъра и показва информация за потребителя. Кодът използва корутини за асинхронна работа с 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()
}

След успешно удостоверяване приложението трябва да изпрати ID Token на собствения си сървър за верификация и създаване на сесия. Препоръчва се използването на HTTPS и предаването на токена в тялото на POST заявката. Сървърът връща собствен токен за сесия, който клиентът запазва в EncryptedSharedPreferences. При всяка следваща заявка към сървъра се използва вътрешният токен, а не ID Token от Google.

Типични грешки при интеграцията и тяхното решение

Първата често срещана грешка е несъответствие на SHA-1 сертификата. Google Cloud Console обвързва OAuth 2.0 Client ID с SHA-1 отпечатъка на сертификата за подписване. Ако приложението се компилира с debug ключ, а Client ID е създаден за release ключа, Google Sign-In ще върне грешка 12501 (SIGN_IN_FAILED). Решение: добавете и двата SHA-1 (debug и release) в Google Cloud Console или използвайте един Client ID за разработка и отделен за продакшън.

Вторият често срещан проблем е грешен serverClientId. Разработчиците често използват Android Client ID вместо Client ID на уеб приложението в параметъра serverClientId на Credential Manager. Google изисква именно ID на уеб клиента за генериране на ID Token, предназначен за сървърна верификация. Android Client ID се използва само за идентификация на приложението по време на удостоверяването. Проверете дали serverClientId отговаря на уеб приложението в Google Cloud Console.

Третата грешка е пренебрегване на обработката на отмяната. Потребителят може да затвори диалоговия прозорец на Google Sign-In, без да завърши удостоверяването. Credential Manager хвърля GetCredentialCancellationException, което трябва да се обработва отделно от другите грешки. Много разработчици третират всички изключения като грешки и показват на потребителя съобщението „Влизането не бе успешно“, въпреки че потребителят просто е отменил операцията. Правилната обработка: при Cancelled — не показвайте нищо, просто се върнете в изходното състояние.