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("SignIn", credential.idToken)
    }

ID Token (JWT) садржи три сегмента: загравље са алгоритмом потписа, пајлоад са подацима корисника (sub, email, name, picture) и потпис за верификацију. Серверски део апликације проверава потпис ID Token-а користећи јавне кључеве Google-а и извлачи идентификатор корисника. Овај приступ гарантује да, чак и ако је клијентска апликација компромитована, нападач неће моћи да фалсификује токен без приступа приватном кључу Google-а.

Credential Manager: нови начин пријаве на Android-у

Credential Manager — је савремени Android API, представљен 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) 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-у се обавља путем GoogleSignIn-iOS SDK-а, доступног преко 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-а. Google SDK користи 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 (исс) — само 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-у. При сваком наредном захтеву ка серверу користи се унутрашњи токен, а не Google ID Token.

Типичне грешке при интеграцији и њихово решавање

Прва честа грешка — непоклапање 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 захтева управо web-client ID за генерисање ID Token-а намењеног за серверску верификацију. Android Client ID се користи само за идентификацију апликације у процесу аутентификације. Проверите да serverClientId одговара веб апликацији у Google Cloud Console-у.

Трећа грешка — игнорисање обраде отказивања. Корисник може да затвори дијалошки прозор Google Sign-In-а без завршетка аутентификације. Credential Manager баца GetCredentialCancellationException које треба обрађивати одвојено од других грешака. Многи програмери све изузетке третирају као грешке, приказујући кориснику поруку „Пријава није успела”, иако је корисник једноставно отказао операцију. Исправна обрада: при Cancelled-у — ништа не приказујте, једноставно се вратите у почетно стање.