Google Sign-In: co to jest, logowanie przez Google i OAuth 2.0 SDK

Czym jest Google Sign-In?

Google Sign-In — to usługa logowania jednokrotnego (Single Sign-On) udostępniana przez Google do uwierzytelniania użytkowników w aplikacjach zewnętrznych. SDK pozwala programistom zintegrować logowanie przez konto Google bez konieczności tworzenia własnego systemu rejestracji. Technologia opiera się na protokole OAuth 2.0 i OpenID Connect, zapewniając uzyskanie danych identyfikacyjnych użytkownika: imię, email, awatar i unikalny identyfikator.

W przeciwieństwie do tradycyjnego uwierzytelniania przez email i hasło, Google Sign-In eliminuje konieczność zapamiętywania haseł i przechodzenia procedury rejestracji. Użytkownik wybiera konto Google na urządzeniu, potwierdza uprawnienia, a aplikacja otrzymuje token dostępu. Według danych Google Identity Platform (2025), aplikacje z Google Sign-In wykazują o 52% więcej udanych rejestracji w porównaniu z formularzem email/hasło.

Google Sign-In obsługuje trzy scenariusze użycia: uwierzytelnianie użytkownika (uzyskanie ID Token), autoryzacja dostępu do Google API (uzyskanie Access Token) i bezproblemowe uwierzytelnianie (Silent Sign-In) dla już autoryzowanych użytkowników. Każdy scenariusz wymaga innego zestawu uprawnień (scopes) i zwraca różne typy tokenów.

Jak działa OAuth 2.0 w Google Sign-In

OAuth 2.0 — to protokół autoryzacji, który pozwala aplikacji uzyskać ograniczony dostęp do zasobów użytkownika bez ujawniania jego danych uwierzytelniających. W kontekście Google Sign-In protokół działa następująco: aplikacja żąda autoryzacji od użytkownika przez Google, otrzymuje tymczasowy kod autoryzacji, wymienia go na tokeny dostępu i używa tych tokenów do wywoływania Google API.

Kluczowa różnica OAuth 2.0 od wcześniejszych protokołów — podział ról między właścicielem zasobu (użytkownik), klientem (aplikacja), serwerem autoryzacji (Google) i serwerem zasobów (Google API). Aplikacja nigdy nie otrzymuje hasła użytkownika — tylko token, który można unieważnić. Google Identity Platform używa specyfikacji OpenID Connect na bazie OAuth 2.0, dodając znormalizowany ID Token w formacie JWT.

ID Token i Access Token: różnice

// Przykład uzyskania ID Token przez 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) zawiera trzy segmenty: nagłówek z algorytmem podpisu, payload z danymi użytkownika (sub, email, name, picture) i podpis do weryfikacji. Serwerowa część aplikacji sprawdza podpis ID Token, używając publicznych kluczy Google, i wyodrębnia identyfikator użytkownika. To podejście gwarantuje, że nawet jeśli aplikacja kliencka zostanie skompromitowana, osoba atakująca nie będzie mogła sfałszować tokenu bez dostępu do prywatnego klucza Google.

Credential Manager: nowy sposób logowania na Android

Credential Manager — to nowoczesne API Androida, przedstawione w 2023 roku, które łączy wszystkie sposoby uwierzytelniania (Google Sign-In, logowanie hasłem, Passkeys) w jeden interfejs użytkownika. W przeciwieństwie do starego GoogleSignInClient, Credential Manager nie wymaga WebView do logowania — używany jest natywny Bottom Sheet, co przyspiesza uwierzytelnianie i poprawia doświadczenie użytkownika.

Główna zaleta Credential Manager — jednolity UX dla wszystkich typów danych uwierzytelniających. Użytkownik widzi jedno okno dialogowe, w którym może wybrać: zalogować się przez Google, użyć Passkey lub wprowadzić hasło. Programista nie musi zarządzać różnymi przepływami uwierzytelniania — Credential Manager abstrahuje interakcję z Google Sign-In, Smart Lock i Passkeys. Google zaleca Credential Manager jako główny sposób integracji Google Sign-In dla Android 14+.

Migracja z GoogleSignInClient na Credential Manager

Migracja z GoogleSignInClient na Credential Manager wymaga zmiany logiki klienckiej: zamiast GoogleSignInOptions używany jest GoogleIdCredentialOption, a zamiast GoogleSignIn.getSignedInAccountFromIntent — obsługa wyniku przez GetCredentialResponse. Część serwerowa nie wymaga zmian, ponieważ ID Token pozostaje w tym samym formacie JWT. Według danych Google I/O 2024, około 40% aplikacji w Google Play już przeszło na Credential Manager.

Konfiguracja Google Sign-In w projekcie Android

Integracja Google Sign-In w aplikacji Android zaczyna się od konfiguracji projektu w Google Cloud Console. Pierwszy krok — utworzenie OAuth 2.0 Client ID dla Android: w tym celu podaje się package name aplikacji i SHA-1 certyfikatu podpisu. Google używa tych danych do weryfikacji, że żądanie uwierzytelnienia pochodzi właśnie z twojej aplikacji, a nie od fałszywego klienta.

Po utworzeniu klienta w Google Cloud Console programista dodaje zależność Credential Manager w build.gradle i konfiguruje GoogleIdCredentialOption z serverClientId. Ważne: serverClientId — to Client ID aplikacji webowej z tego samego projektu Google Cloud, który jest używany przez część serwerową do weryfikacji ID Token. Aplikacja kliencka nie sprawdza tokenu — tylko go otrzymuje i przekazuje na serwer.

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

// Żądanie Google Sign-In przez 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 otrzymaniu ID Token na kliencie, aplikacja wysyła go na swój serwer, gdzie następuje weryfikacja. Serwer sprawdza podpis JWT za pomocą publicznych kluczy Google (dostępnych pod URL https://www.googleapis.com/oauth2/v3/certs), czas ważności tokenu (exp) i wartość pola aud — powinna być zgodna z serverClientId. Po weryfikacji serwer tworzy własną sesję, na przykład wydaje wewnętrzny JWT lub Session Token.

Google Sign-In na iOS: konfiguracja i cechy

Integracja Google Sign-In na iOS odbywa się przez SDK GoogleSignIn-iOS, dostępne przez CocoaPods lub Swift Package Manager. Proces konfiguracji obejmuje utworzenie Client ID dla iOS w Google Cloud Console (z podaniem Bundle Identifier), dodanie URL Scheme dla wywołania zwrotnego i konfigurację AppDelegate do obsługi URL zwracanego przez Google po uwierzytelnieniu.

Ważna różnica wersji iOS Google Sign-In od Android — konieczność konfiguracji URL Scheme i Info.plist. GoogleSDK używa uniwersalnych linków (Universal Links) do wywołania zwrotnego, ale do fallback wymagany jest URL Scheme postaci `com.googleusercontent.apps.[CLIENT_ID]`. Wymagana jest również konfiguracja Keychain Sharing do przechowywania refresh token między uruchomieniami aplikacji. Według dokumentacji Google Identity, iOS SDK obsługuje iOS 15 i nowsze.

// Konfiguracja 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
            // Wysyłanie ID Token na serwer
            sendTokenToBackend(idToken)
        }
    }
}

Na iOS Google Sign-In obsługuje Silent Sign-In dla użytkowników, którzy wcześniej się autoryzowali. Metoda restorePreviousSignIn automatycznie przywraca sesję, jeśli refresh token został zapisany w Keychain. Jest to szczególnie ważne dla aplikacji, w których użytkownik nie powinien logować się ponownie przy każdym uruchomieniu. Według Google, Silent Sign-In jest skuteczny w 85% przypadków na urządzeniach z aktywną sesją Google.

Obsługa tokenów i bezpieczeństwo

Bezpieczeństwo Google Sign-In opiera się na trzech poziomach: weryfikacja kliencka (podpis SHA-1 aplikacji), szyfrowanie transportowe (HTTPS/TLS) i podpis kryptograficzny JWT. ID Token otrzymany od Google jest podpisany przy użyciu algorytmu RS256 (RSA z SHA-256). Serwerowa część aplikacji musi sprawdzać podpis tokenu, czas ważności i issuer (iss) — tylko accounts.google.com.

Access Token — to tymczasowy token (żyje 1 godzinę), który daje dostęp do Google API (Google Drive, Google Calendar, YouTube itd.). W przeciwieństwie do ID Token, Access Token nie zawiera informacji o użytkowniku — to opaque-string, którego serwer Google API używa do autoryzacji żądania. Refresh Token — długożyjący token, pozwalający uzyskiwać nowe Access Token bez ponownego logowania użytkownika. Refresh Token jest wydawany tylko przy pierwszym logowaniu i może być unieważniony przez użytkownika w ustawieniach konta Google.

// Przykład przetwarzania ID Token na serwerze (pseudokod)
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 i zarządzanie sesją

Zalecenia bezpieczeństwa: nigdy nie przesyłaj ID Token przez niezabezpieczone kanały, używaj HTTPS dla wszystkich żądań do serwera, sprawdzaj czas ważności tokenu (pole exp) i issuer (iss). Na kliencie nie przechowuj tokenów w SharedPreferences bez szyfrowania — używaj EncryptedSharedPreferences lub Android Keystore. Google Sign-In nie jest przeznaczony do uwierzytelniania serwer-serwer — do tego służą konta serwisowe (Service Accounts).

Przykład kodu: integracja Google Sign-In w Kotlin

Pełny przykład integracji Google Sign-In w aplikacji Android z użyciem Credential Manager i ViewModel. Aplikacja wyświetla przycisk logowania, po uwierzytelnieniu wysyła ID Token na serwer i pokazuje informacje o użytkowniku. Kod używa coroutines do asynchronicznej pracy z 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 pomyślnym uwierzytelnieniu aplikacja powinna wysłać ID Token na swój serwer w celu weryfikacji i utworzenia sesji. Zaleca się używanie HTTPS i przesyłanie tokenu w ciele żądania POST. Serwer zwraca własny token sesji, który klient przechowuje w EncryptedSharedPreferences. Przy każdym kolejnym żądaniu do serwera używany jest wewnętrzny token, a nie ID Token Google.

Typowe błędy przy integracji i ich rozwiązania

Pierwszy częsty błąd — niezgodność SHA-1 certyfikatu. Google Cloud Console przypisuje OAuth 2.0 Client ID do odcisku SHA-1 certyfikatu podpisu. Jeśli aplikacja jest budowana z debug-kluczem, a Client ID został utworzony dla release-klucza, Google Sign-In zwróci błąd 12501 (SIGN_IN_FAILED). Rozwiązanie — dodaj oba SHA-1 (debug i release) w Google Cloud Console lub użyj jednego Client ID do rozwoju i osobnego do produkcji.

Drugi częsty problem — nieprawidłowy serverClientId. Programiści często używają Client ID Android zamiast Client ID aplikacji webowej w parametrze serverClientId Credential Manager. Google wymaga właśnie web-client ID do generowania ID Token przeznaczonego do weryfikacji serwerowej. Android Client ID jest używany tylko do identyfikacji aplikacji w procesie uwierzytelniania. Sprawdź, czy serverClientId odpowiada aplikacji webowej w Google Cloud Console.

Trzeci błąd — ignorowanie obsługi anulowania. Użytkownik może zamknąć okno dialogowe Google Sign-In, nie kończąc uwierzytelniania. Credential Manager wyrzuca GetCredentialCancellationException, które należy obsługiwać oddzielnie od innych błędów. Wielu programistów obsługuje wszystkie wyjątki jako błędy, pokazując użytkownikowi komunikat „Logowanie nie powiodło się”, mimo że użytkownik po prostu anulował operację. Prawidłowa obsługa: przy Cancelled — nic nie pokazuj, po prostu wróć do stanu początkowego.