Google Sign-In: co to je, přihlášení přes Google a OAuth 2.0 SDK

Co je Google Sign-In?

Google Sign-In — je služba jednotného přihlášení (Single Sign-On) poskytovaná Google pro autentizaci uživatelů v aplikacích třetích stran. SDK umožňuje vývojářům integrovat přihlášení prostřednictvím účtu Google bez nutnosti vytvářet vlastní registrační systém. Technologie je založena na protokolu OAuth 2.0 a OpenID Connect, což umožňuje získání identifikačních údajů uživatele: jméno, email, avatar a jedinečný identifikátor.

Na rozdíl od tradiční autentizace pomocí emailu a hesla, Google Sign-In odstraňuje nutnost pamatovat si hesla a procházet registrační procedurou. Uživatel vybere účet Google na zařízení, potvrdí oprávnění a aplikace získá přístupový token. Podle Google Identity Platform (2025), aplikace s Google Sign-In vykazují o 52% více úspěšných registrací ve srovnání s formulářem email/heslo.

Google Sign-In podporuje tři scénáře použití: autentizaci uživatele (získání ID Token), autorizaci přístupu k Google API (získání Access Token) a bezproblémovou autentizaci (Silent Sign-In) pro již autorizované uživatele. Každý scénář vyžaduje jinou sadu oprávnění (scopes) a vrací různé typy tokenů.

Jak funguje OAuth 2.0 v Google Sign-In

OAuth 2.0 — je autorizační protokol, který umožňuje aplikaci získat omezený přístup ke zdrojům uživatele bez odhalení jeho přihlašovacích údajů. V kontextu Google Sign-In protokol funguje následovně: aplikace požaduje autorizaci od uživatele prostřednictvím Google, obdrží dočasný autorizační kód, vymění jej za přístupové tokeny a použije tyto tokeny k volání Google API.

Klíčový rozdíl OAuth 2.0 od starších protokolů — oddělení rolí mezi vlastníkem zdroje (uživatel), klientem (aplikace), autorizačním serverem (Google) a serverem zdrojů (Google API). Aplikace nikdy nezíská heslo uživatele — pouze token, který lze odvolat. Google Identity Platform používá specifikaci OpenID Connect nad OAuth 2.0, čímž přidává standardizovaný ID Token ve formátu JWT.

ID Token a Access Token: rozdíly

// Příklad získání ID Token přes 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) obsahuje tři segmenty: záhlaví s algoritmem podpisu, payload s údaji uživatele (sub, email, name, picture) a podpis pro ověření. Serverová část aplikace ověřuje podpis ID Token pomocí veřejných klíčů Google a extrahuje identifikátor uživatele. Tento přístup zaručuje, že i když je klientská aplikace kompromitována, útočník nebude moci zfalšovat token bez přístupu k soukromému klíči Google.

Credential Manager: nový způsob přihlášení na Android

Credential Manager — je moderní Android API, představené v roce 2023, které spojuje všechny způsoby autentizace (Google Sign-In, přihlášení heslem, Passkeys) do jednoho uživatelského rozhraní. Na rozdíl od starého GoogleSignInClient, Credential Manager nevyžaduje WebView pro přihlášení — používá se nativní Bottom Sheet, což urychluje autentizaci a zlepšuje uživatelský zážitek.

Hlavní výhoda Credential Manager — jednotné UX pro všechny typy přihlašovacích údajů. Uživatel vidí jedno dialogové okno, kde si může vybrat: přihlásit se přes Google, použít Passkey nebo zadat heslo. Vývojář nemusí spravovat různé toky autentizace — Credential Manager abstrahuje interakci s Google Sign-In, Smart Lock a Passkeys. Google doporučuje Credential Manager jako hlavní způsob integrace Google Sign-In pro Android 14+.

Migrace z GoogleSignInClient na Credential Manager

Migrace z GoogleSignInClient na Credential Manager vyžaduje změnu klientské logiky: místo GoogleSignInOptions se používá GoogleIdCredentialOption a místo GoogleSignIn.getSignedInAccountFromIntent — zpracování výsledku prostřednictvím GetCredentialResponse. Serverová část nevyžaduje změny, protože ID Token zůstává ve stejném formátu JWT. Podle Google I/O 2024, přibližně 40% aplikací v Google Play již přešlo na Credential Manager.

Nastavení Google Sign-In v Android projektu

Integrace Google Sign-In v aplikaci Android začíná nastavením projektu v Google Cloud Console. Prvním krokem — vytvoření OAuth 2.0 Client ID pro Android: k tomu se uvádí package name aplikace a SHA-1 podpisového certifikátu. Google používá tato data k ověření, že požadavek na autentizaci pochází skutečně z vaší aplikace, nikoli od falešného klienta.

Po vytvoření klienta v Google Cloud Console, vývojář přidá závislost Credential Manager do build.gradle a nakonfiguruje GoogleIdCredentialOption s serverClientId. Důležité: serverClientId — je Client ID webové aplikace ze stejného Google Cloud projektu, který serverová část používá k ověření ID Token. Klientská aplikace token neověřuje — pouze jej obdrží a předá serveru.

// 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")

// Žádost Google Sign-In přes 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
}

Po obdržení ID Token na klientovi, aplikace jej odešle na svůj server k ověření a vytvoření relace. Server ověřuje podpis JWT pomocí veřejných klíčů Google (dostupných na URL https://www.googleapis.com/oauth2/v3/certs), dobu platnosti tokenu (exp) a hodnotu pole aud — musí se shodovat s serverClientId. Po ověření server vytvoří vlastní relaci, například vydá interní JWT nebo Session Token.

Google Sign-In na iOS: nastavení a vlastnosti

Integrace Google Sign-In na iOS se provádí prostřednictvím SDK GoogleSignIn-iOS, dostupného přes CocoaPods nebo Swift Package Manager. Proces nastavení zahrnuje vytvoření Client ID pro iOS v Google Cloud Console (s uvedením Bundle Identifier), přidání URL Scheme pro zpětné volání a konfiguraci AppDelegate pro zpracování URL vraceného Google po autentizaci.

Důležitý rozdíl iOS verze Google Sign-In od Android — nutnost konfigurace URL Scheme a Info.plist. Google SDK používá Universal Links pro zpětné volání, ale pro fallback je vyžadována URL Scheme tvaru `com.googleusercontent.apps.[CLIENT_ID]`. Také je vyžadována konfigurace Keychain Sharing pro ukládání refresh token mezi spuštěními aplikace. Podle dokumentace Google Identity, iOS SDK podporuje iOS 15 a vyšší.

// Nastavení Google Sign-In na 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
            // Odeslání ID Token na server
            sendTokenToBackend(idToken)
        }
    }
}

Na iOS Google Sign-In podporuje Silent Sign-In pro uživatele, kteří se dříve autorizovali. Metoda restorePreviousSignIn automaticky obnoví relaci, pokud je refresh token uložen v Keychain. To je důležité zejména pro aplikace, kde by se uživatel neměl přihlašovat znovu při každém spuštění. Podle Google, Silent Sign-In je úspěšný v 85% případů na zařízeních s aktivní relací Google.

Zpracování tokenů a bezpečnost

Bezpečnost Google Sign-In je postavena na třech úrovních: klientské ověření (SHA-1 podpis aplikace), šifrování přenosu (HTTPS/TLS) a kryptografický podpis JWT. ID Token obdržený od Google je podepsán pomocí algoritmu RS256 (RSA s SHA-256). Serverová část aplikace musí ověřovat podpis tokenu, dobu platnosti a issuer (iss) — pouze accounts.google.com.

Access Token — je dočasný token (platí 1 hodinu), který poskytuje přístup k Google API (Google Drive, Google Calendar, YouTube atd.). Na rozdíl od ID Token, Access Token neobsahuje informace o uživateli — je to opaque řetězec, který server Google API používá k autorizaci požadavku. Refresh Token — dlouhodobý token, který umožňuje získávat nové Access Token bez opětovného přihlášení uživatele. Refresh Token je vydán pouze při prvním přihlášení a může být odvolán uživatelem v nastavení účtu Google.

// Příklad zpracování ID Token na serveru (pseudokód)
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 a správa relace

Bezpečnostní doporučení: nikdy nepřenášejte ID Token nezabezpečenými kanály, používejte HTTPS pro všechny požadavky na server, kontrolujte dobu platnosti tokenu (pole exp) a issuer (iss). Na klientovi neukládejte tokeny v SharedPreferences bez šifrování — používejte EncryptedSharedPreferences nebo Android Keystore. Google Sign-In není určen pro autentizaci server-server — k tomu se používají Service Accounts.

Příklad kódu: integrace Google Sign-In v Kotlin

Úplný příklad integrace Google Sign-In v aplikaci Android s použitím Credential Manager a ViewModel. Aplikace zobrazí tlačítko přihlášení, po autentizaci odešle ID Token na server a zobrazí informace o uživateli. Kód používá korutiny pro asynchronní práci s 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()
}

Po úspěšné autentizaci by aplikace měla odeslat ID Token na svůj server k ověření a vytvoření relace. Doporučuje se používat HTTPS a přenášet token v těle požadavku POST. Server vrátí vlastní token relace, který klient uloží do EncryptedSharedPreferences. Při každém následném požadavku na server se používá interní token, nikoli Google ID Token.

Typické chyby při integraci a jejich řešení

První častou chybou — neshoda SHA-1 certifikátu. Google Cloud Console připojuje OAuth 2.0 Client ID k otisku SHA-1 podpisového certifikátu. Pokud je aplikace sestavena s debug klíčem, ale Client ID byl vytvořen pro release klíč, Google Sign-In vrátí chybu 12501 (SIGN_IN_FAILED). Řešení — přidejte oba SHA-1 (debug a release) do Google Cloud Console nebo použijte jeden Client ID pro vývoj a samostatný pro produkci.

Druhý častý problém — nesprávný serverClientId. Vývojáři často používají Android Client ID místo Client ID webové aplikace v parametru serverClientId Credential Manager. Google vyžaduje právě web-client ID pro generování ID Token určeného pro serverové ověření. Android Client ID se používá pouze k identifikaci aplikace v procesu autentizace. Zkontrolujte, zda serverClientId odpovídá webové aplikaci v Google Cloud Console.

Třetí chyba — ignorování zpracování zrušení. Uživatel může zavřít dialog Google Sign-In bez dokončení autentizace. Credential Manager vyvolává GetCredentialCancellationException, které je třeba zpracovávat odděleně od ostatních chyb. Mnoho vývojářů zpracovává všechny výjimky jako chyby a zobrazuje uživateli zprávu „Přihlášení se nezdařilo”, i když uživatel jednoduše zrušil operaci. Správné zpracování: při Cancelled — nic nezobrazujte, jednoduše se vraťte do původního stavu.