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, обеспечивая получение идентификационной информации о пользователе: имя, email, аватар и уникальный идентификатор.

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

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("SignIn", 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 dependency в build.gradle и конфигурирует GoogleIdCredentialOption с serverClientId. Важно: serverClientId — это Client ID веб-приложения из того же проекта Google Cloud, который используется серверной частью для верификации ID Token. Клиентское приложение не проверяет токен — оно только получает его и передаёт на сервер.

// 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 через 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 (доступных по URL 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("Sign in failed: \(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. Разработчики часто используют Client ID Android вместо Client ID веб-приложения в параметре serverClientId Credential Manager. Google требует именно веб-клиент ID для генерации ID Token, предназначенного для серверной верификации. Android Client ID используется только для идентификации приложения в процессе аутентификации. Проверьте, что serverClientId соответствует веб-приложению в Google Cloud Console.

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