Google Sign-In: vad det är, inloggning via Google och OAuth 2.0 SDK

Vad är Google Sign-In?

Google Sign-In är en enkel inloggningstjänst (Single Sign-On) som tillhandahålls av Google för autentisering av användare i tredjepartsapplikationer. SDK:n gör det möjligt för utvecklare att integrera inloggning via Google-konto utan att behöva bygga ett eget registreringssystem. Tekniken baseras på protokollet OAuth 2.0 och OpenID Connect och ger tillgång till identitetsinformation om användaren: namn, e-post, avatar och en unik identifierare.

Till skillnad från traditionell autentisering med e-post och lösenord eliminerar Google Sign-In behovet av att komma ihåg lösenord och genomgå registreringsprocessen. Användaren väljer ett Google-konto på enheten, bekräftar behörigheterna, och applikationen får en åtkomsttoken. Enligt Google Identity Platform (2025) visar appar med Google Sign-In 52% fler lyckade registreringar jämfört med e-post/lösenordsformulär.

Google Sign-In stöder tre användningsscenarier: användarautentisering (hämta ID Token), auktorisering av åtkomst till Google API (hämta Access Token) och sömlös autentisering (Silent Sign-In) för redan auktoriserade användare. Varje scenario kräver en annan uppsättning behörigheter (scopes) och returnerar olika typer av tokens.

Hur fungerar OAuth 2.0 i Google Sign-In

OAuth 2.0 är ett auktoriseringsprotokoll som gör det möjligt för applikationen att få begränsad åtkomst till användarens resurser utan att avslöja dennes inloggningsuppgifter. I samband med Google Sign-In fungerar protokollet på följande sätt: applikationen begär auktorisering från användaren via Google, får en tillfällig auktoriseringskod, byter den mot åtkomsttokens och använder dessa tokens för att anropa Google API.

Den viktigaste skillnaden mellan OAuth 2.0 och tidigare protokoll är uppdelningen av roller mellan resursägaren (användaren), klienten (applikationen), auktoriseringsservern (Google) och resursservern (Google API). Applikationen får aldrig användarens lösenord — bara en token som kan återkallas. Google Identity Platform använder specifikationen OpenID Connect ovanpå OAuth 2.0 och lägger till en standardiserad ID Token i JWT-format.

ID Token och Access Token: skillnader

// Exempel på att hämta ID Token via 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("Logga in", credential.idToken)
    }

ID Token (JWT) innehåller tre segment: en rubrik med signeringsalgoritmen, en payload med användarens data (sub, email, name, picture) och en signatur för verifiering. Applikationens serverdel verifierar ID Tokens signatur med hjälp av Googles publika nycklar och extraherar användarens identifierare. Denna metod garanterar att även om klientapplikationen komprometteras kan en angripare inte förfalska token utan åtkomst till Googles privata nyckel.

Credential Manager: nytt sätt att logga in på Android

Credential Manager är en modern Android-API som presenterades 2023 och som förenar alla autentiseringsmetoder (Google Sign-In, lösenordsinloggning, Passkeys) i ett enda användargränssnitt. Till skillnad från den gamla GoogleSignInClient kräver Credential Manager ingen WebView för inloggning — en inbyggd Bottom Sheet används, vilket snabbar upp autentiseringen och förbättrar användarupplevelsen.

Den främsta fördelen med Credential Manager är ett enhetligt UX för alla typer av inloggningsuppgifter. Användaren ser en enda dialogruta där hen kan välja: logga in via Google, använda en Passkey eller ange lösenord. Utvecklaren behöver inte hantera olika autentiseringsflöden — Credential Manager abstraherar interaktionen med Google Sign-In, Smart Lock och Passkeys. Google rekommenderar Credential Manager som det primära sättet att integrera Google Sign-In för Android 14+.

Migrering från GoogleSignInClient till Credential Manager

Migrering från GoogleSignInClient till Credential Manager kräver ändringar i klientlogiken: i stället för GoogleSignInOptions används GoogleIdCredentialOption, och i stället för GoogleSignIn.getSignedInAccountFromIntent hanteras resultatet via GetCredentialResponse. Serverdelen kräver inga ändringar, eftersom ID Token fortfarande har samma JWT-format. Enligt Google I/O 2024 har cirka 40% av apparna i Google Play redan gått över till Credential Manager.

Konfigurera Google Sign-In i ett Android-projekt

Integreringen av Google Sign-In i en Android-app börjar med att konfigurera projektet i Google Cloud Console. Det första steget är att skapa ett OAuth 2.0 Client ID för Android: du anger appens package name och SHA-1 för signeringscertifikatet. Google använder dessa uppgifter för att verifiera att autentiseringsbegäran verkligen kommer från din app och inte från en förfalskad klient.

Efter att klienten skapats i Google Cloud Console lägger utvecklaren till Credential Manager-beroendet i build.gradle och konfigurerar GoogleIdCredentialOption med serverClientId. Viktigt: serverClientId är Client ID för webbapplikationen i samma Google Cloud-projekt, som serverdelen använder för att verifiera ID Token. Klientapplikationen verifierar inte token — den hämtar bara token och skickar den till servern.

// build.gradle (app) beroenden
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")

// Begär Google Sign-In via 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
}

Efter att ID Token hämtats på klienten skickar applikationen den till sin egen server, där verifieringen utförs. Servern verifierar JWT-signaturen med hjälp av Googles publika nycklar (tillgängliga på https://www.googleapis.com/oauth2/v3/certs), tokenens giltighetstid (exp) och värdet på fältet aud — det måste matcha serverClientId. Efter verifieringen skapar servern en egen session, till exempel genom att utfärda en intern JWT eller Session Token.

Google Sign-In på iOS: konfigurering och specifika egenskaper

Integreringen av Google Sign-In på iOS görs via SDK:n GoogleSignIn-iOS, som finns tillgänglig via CocoaPods eller Swift Package Manager. Konfigureringsprocessen omfattar att skapa ett Client ID för iOS i Google Cloud Console (med angivande av Bundle Identifier), lägga till URL Scheme för återanrop samt konfigurera AppDelegate för att hantera den URL som Google returnerar efter autentisering.

En viktig skillnad mellan iOS-versionen av Google Sign-In och Android är behovet av att konfigurera URL Scheme och Info.plist. GoogleSDK använder Universal Links för återanrop, men för fallback krävs ett URL Scheme av typen `com.googleusercontent.apps.[CLIENT_ID]`. Du behöver också konfigurera Keychain Sharing för att spara refresh token mellan appens starttillfällen. Enligt Googles dokumentation stöder iOS SDK iOS 15 och senare.

// Konfigurera Google Sign-In på 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("Inloggningen misslyckades: \(error)")
                return
            }
            let idToken = result.user.idToken.tokenString
            // Skicka ID Token till servern
            sendTokenToBackend(idToken)
        }
    }
}

På iOS stöder Google Sign-In Silent Sign-In för användare som tidigare har auktoriserats. Metoden restorePreviousSignIn återställer automatiskt sessionen om refresh token har sparats i Keychain. Detta är särskilt viktigt för appar där användaren inte ska behöva logga in igen vid varje start. Enligt Google lyckas Silent Sign-In i 85% av fallen på enheter med en aktiv Google-session.

Tokenhantering och säkerhet

Säkerheten i Google Sign-In bygger på tre nivåer: klientverifiering (appens SHA-1-signatur), transportkryptering (HTTPS/TLS) och kryptografisk signering av JWT. ID Token som hämtas från Google signeras med algoritmen RS256 (RSA med SHA-256). Applikationens serverdel måste verifiera tokens signatur, giltighetstid och issuer (iss) — endast accounts.google.com.

Access Token är en tillfällig token (gäller i 1 timme) som ger åtkomst till Google API (Google Drive, Google Calendar, YouTube osv.). Till skillnad från ID Token innehåller Access Token ingen information om användaren — det är en opaque-sträng som Googles API-server använder för att auktorisera begäran. Refresh Token är en långlivad token som gör det möjligt att hämta nya Access Token utan att användaren loggar in igen. Refresh Token utfärdas bara vid första inloggningen och kan återkallas av användaren i Googles kontoinställningar.

// Exempel på hantering av ID Token på servern (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 och sessionshantering

Säkerhetsrekommendationer: skicka aldrig ID Token via osäkra kanaler, använd HTTPS för alla förfrågningar till servern, kontrollera tokens giltighetstid (fältet exp) och issuer (iss). På klienten ska du inte lagra tokens i SharedPreferences utan kryptering — använd EncryptedSharedPreferences eller Android Keystore. Google Sign-In är inte avsett för server-till-server-autentisering — för detta används tjänstekonton (Service Accounts).

Kodexempel: integrera Google Sign-In i Kotlin

Komplett exempel på integrering av Google Sign-In i en Android-app med hjälp av Credential Manager och ViewModel. Appen visar en inloggningsknapp, skickar efter autentisering ID Token till servern och visar information om användaren. Koden använder coroutines för asynkron hantering av 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()
}

Efter lyckad autentisering ska applikationen skicka ID Token till sin egen server för verifiering och sessionsskapande. Det rekommenderas att använda HTTPS och skicka token i POST-begärans brödtext. Servern returnerar en egen sessionstoken som klienten sparar i EncryptedSharedPreferences. Vid varje efterföljande begäran till servern används den interna token, inte Googles ID Token.

Vanliga fel vid integrering och deras lösningar

Det första vanliga felet är att SHA-1-certifikatet inte stämmer. Google Cloud Console binder OAuth 2.0 Client ID till SHA-1-avtrycket för signeringscertifikatet. Om appen byggs med en debug-nyckel medan Client ID skapats för release-nyckeln returnerar Google Sign-In fel 12501 (SIGN_IN_FAILED). Lösning: lägg till båda SHA-1 (debug och release) i Google Cloud Console eller använd ett Client ID för utveckling och ett separat för produktion.

Det andra vanliga problemet är felaktig serverClientId. Utvecklare använder ofta Android Client ID i stället för webbapplikationens Client ID i parametern serverClientId i Credential Manager. Google kräver just webbklientens ID för att generera en ID Token avsedd för serververifiering. Android Client ID används bara för att identifiera applikationen under autentiseringen. Kontrollera att serverClientId motsvarar webbapplikationen i Google Cloud Console.

Det tredje felet är att avbrytningshantering ignoreras. Användaren kan stänga dialogrutan för Google Sign-In utan att slutföra autentiseringen. Credential Manager kastar GetCredentialCancellationException, som måste hanteras separat från andra fel. Många utvecklare behandlar alla undantag som fel och visar användaren meddelandet “Inloggningen misslyckades”, trots att användaren bara avbröt åtgärden. Rätt hantering: vid Cancelled — visa ingenting, bara återgå till utgångsläget.