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). Серверна частина додатка повинна перевіряти підпис токена, термін дії та емітента (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) та емітента (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 — нічого не показувати, просто повернутися до початкового стану.