Google Sign-In: wat is het, inloggen via Google en OAuth 2.0 SDK

Auteur: IT Sectr Gepubliceerd: 2026-04-29 Leestijd: 10 min

Google Sign-In — is een SDK van Google die gebruikersauthenticatie via Google-accounts in mobiele en webapplicaties implementeert. Aan de basis van de technologie ligt het OAuth 2.0-protocol, waarmee toegangstokens voor Google API kunnen worden verkregen zonder het wachtwoord aan een derde partij te geven. Meer dan 3 miljard Android-apparaten ondersteunen Google Sign-In, wat het de meest gebruikte inlogmethode in mobiele apps maakt. Volgens Google Identity Platform, 2025 verkort SDK-integratie de registratietijd met 60% en verhoogt het de gebruikersconversie.

Belangrijkste

  • Google Sign-In — SDK voor authenticatie via Google-account op basis van OAuth 2.0
  • OAuth 2.0 — autorisatieprotocol waarbij de app een toegangstoken ontvangt zonder het wachtwoord van de gebruiker
  • Credential Manager — moderne Android API voor inloggen via Google zonder WebView
  • ID Token — JSON Web Token (JWT) met identiteitsgegevens van de gebruiker
  • Cross-platform — Google Sign-In werkt op Android, iOS, web en desktop platforms

Wat is Google Sign-In?

Google Sign-In — is een single sign-on service van Google voor gebruikersauthenticatie in externe applicaties. De SDK stelt ontwikkelaars in staat om inloggen via een Google-account te integreren zonder een eigen registratiesysteem te maken. De technologie is gebaseerd op het OAuth 2.0-protocol en OpenID Connect, en zorgt voor het verkrijgen van identificatiegegevens van de gebruiker: naam, e-mail, avatar en een unieke identificatie.

In tegenstelling tot traditionele authenticatie via e-mail en wachtwoord, elimineert Google Sign-In de noodzaak om wachtwoorden te onthouden en het registratieproces te doorlopen. De gebruiker selecteert een Google-account op het apparaat, bevestigt de machtigingen en de app ontvangt een toegangstoken. Volgens Google Identity Platform (2025) laten apps met Google Sign-In 52% meer succesvolle registraties zien in vergelijking met het e-mail/wachtwoord formulier.

Google Sign-In ondersteunt drie gebruiksscenario’s: gebruikersauthenticatie (verkrijgen van ID Token), autorisatie van toegang tot Google API (verkrijgen van Access Token) en naadloze authenticatie (Silent Sign-In) voor reeds geautoriseerde gebruikers. Elk scenario vereist een andere set machtigingen (scopes) en retourneert verschillende soorten tokens.

Hoe werkt OAuth 2.0 in Google Sign-In

OAuth 2.0 — is een autorisatieprotocol waarmee een app beperkte toegang kan krijgen tot de bronnen van een gebruiker zonder diens inloggegevens prijs te geven. In de context van Google Sign-In werkt het protocol als volgt: de app vraagt autorisatie aan de gebruiker via Google, ontvangt een tijdelijke autorisatiecode, wisselt deze in voor toegangstokens en gebruikt deze tokens om Google API aan te roepen.

Het belangrijkste verschil van OAuth 2.0 met oudere protocollen — de scheiding van rollen tussen de resource-eigenaar (gebruiker), client (app), autorisatieserver (Google) en resource-server (Google API). De app krijgt nooit het wachtwoord van de gebruiker — alleen een token dat kan worden ingetrokken. Google Identity Platform gebruikt de OpenID Connect-specificatie bovenop OAuth 2.0, met een gestandaardiseerde ID Token in JWT-formaat.

ID Token en Access Token: verschillen

kotlin
// Voorbeeld van het verkrijgen van 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("SignIn", credential.idToken)
    }

ID Token (JWT) bevat drie segmenten: een header met het handtekeningalgoritme, een payload met gebruikersgegevens (sub, email, name, picture) en een handtekening voor verificatie. Het servergedeelte van de app verifieert de ID Token-handtekening met behulp van de openbare sleutels van Google en haalt de gebruikersidentificatie op. Deze aanpak garandeert dat, zelfs als de client-app is gecompromitteerd, een aanvaller het token niet kan vervalsen zonder toegang tot de privésleutel van Google.

Credential Manager: nieuwe manier van inloggen op Android

Credential Manager — is een moderne Android API, geïntroduceerd in 2023, die alle authenticatiemethoden (Google Sign-In, wachtwoordlogin, Passkeys) combineert in één gebruikersinterface. In tegenstelling tot de oude GoogleSignInClient heeft Credential Manager geen WebView nodig voor inloggen — er wordt een native Bottom Sheet gebruikt, wat de authenticatie versnelt en de gebruikerservaring verbetert.

Het belangrijkste voordeel van Credential Manager — uniforme UX voor alle soorten inloggegevens. De gebruiker ziet één dialoogvenster waarin hij kan kiezen: inloggen via Google, Passkey gebruiken of wachtwoord invoeren. De ontwikkelaar hoeft geen verschillende authenticatiestromen te beheren — Credential Manager abstraheert de interactie met Google Sign-In, Smart Lock en Passkeys. Google beveelt Credential Manager aan als primaire integratiemethode voor Google Sign-In op Android 14+.

ParameterGoogleSignInClient (verouderd)Credential Manager
Minimale APIAndroid 4.4 (API 19)Android 4.4 (API 19)
InterfaceWebView / BottomSheetNative BottomSheet
Ondersteuning PasskeysNeeJa
SDK-grootte~500 KB~150 KB
StatusDeprecated (2024)Aanbevolen door Google

Migratie van GoogleSignInClient naar Credential Manager

Migratie van GoogleSignInClient naar Credential Manager vereist wijziging van de clientlogica: in plaats van GoogleSignInOptions wordt GoogleIdCredentialOption gebruikt, en in plaats van GoogleSignIn.getSignedInAccountFromIntent — resultaatverwerking via GetCredentialResponse. Het servergedeelte vereist geen wijzigingen omdat ID Token in hetzelfde JWT-formaat blijft. Volgens Google I/O 2024 is ongeveer 40% van de apps in Google Play al overgestapt op Credential Manager.

Google Sign-In configureren in een Android-project

Integratie van Google Sign-In in een Android-app begint met het configureren van het project in Google Cloud Console. De eerste stap — het maken van een OAuth 2.0 Client ID voor Android: hiervoor worden de package name van de app en de SHA-1 van het ondertekeningscertificaat opgegeven. Google gebruikt deze gegevens om te verifiëren dat het authenticatieverzoek afkomstig is van uw app en niet van een valse client.

Na het aanmaken van de client in Google Cloud Console voegt de ontwikkelaar de Credential Manager-afhankelijkheid toe in build.gradle en configureert GoogleIdCredentialOption met serverClientId. Belangrijk: serverClientId — is de Client ID van de web-app uit hetzelfde Google Cloud-project, die door het servergedeelte wordt gebruikt voor ID Token-verificatie. De client-app verifieert het token niet — het ontvangt het alleen en stuurt het door naar de server.

kotlin
// 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 verzoek 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
}

Na ontvangst van de ID Token op de client stuurt de app deze naar zijn eigen server voor verificatie en het creëren van een sessie. De server verifieert de JWT-handtekening met behulp van de openbare sleutels van Google (beschikbaar op URL https://www.googleapis.com/oauth2/v3/certs), de geldigheidsduur van het token (exp) en de waarde van het veld aud — deze moet overeenkomen met serverClientId. Na verificatie maakt de server zijn eigen sessie aan, bijvoorbeeld door een interne JWT of Session Token uit te geven.

Google Sign-In op iOS: configuratie en functies

Integratie van Google Sign-In op iOS gebeurt via de GoogleSignIn-iOS SDK, beschikbaar via CocoaPods of Swift Package Manager. Het configuratieproces omvat het maken van een Client ID voor iOS in Google Cloud Console (met opgave van Bundle Identifier), het toevoegen van een URL Scheme voor de callback en het configureren van AppDelegate voor het verwerken van de URL die door Google wordt geretourneerd na authenticatie.

Een belangrijk verschil van de iOS-versie van Google Sign-In met Android — de noodzaak om URL Scheme en Info.plist te configureren. Google SDK gebruikt Universal Links voor de callback, maar voor fallback is een URL Scheme van de vorm `com.googleusercontent.apps.[CLIENT_ID]` vereist. Ook is Keychain Sharing-configuratie vereist voor het bewaren van de refresh token tussen app-starts. Volgens Google Identity-documentatie ondersteunt de iOS SDK iOS 15 en hoger.

swift
// Google Sign-In configureren op 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 naar server sturen
            sendTokenToBackend(idToken)
        }
    }
}

Op iOS ondersteunt Google Sign-In Silent Sign-In voor gebruikers die eerder zijn geautoriseerd. De methode restorePreviousSignIn herstelt automatisch de sessie als de refresh token is opgeslagen in de Keychain. Dit is vooral belangrijk voor apps waarbij de gebruiker niet bij elke start opnieuw moet inloggen. Volgens Google is Silent Sign-In succesvol in 85% van de gevallen op apparaten met een actieve Google-sessie.

Tokenbeheer en beveiliging

Beveiliging van Google Sign-In is gebouwd op drie niveaus: clientverificatie (SHA-1 handtekening van de app), transportversleuteling (HTTPS/TLS) en cryptografische ondertekening van JWT. De ID Token van Google is ondertekend met behulp van het RS256-algoritme (RSA met SHA-256). Het servergedeelte van de app moet de tokenhandtekening, de geldigheidsduur en de issuer (iss) verifiëren — alleen accounts.google.com.

Access Token — is een tijdelijk token (1 uur geldig) dat toegang geeft tot Google API (Google Drive, Google Calendar, YouTube enz.). In tegenstelling tot ID Token bevat Access Token geen informatie over de gebruiker — het is een opaque string die de Google API-server gebruikt voor het autoriseren van verzoeken. Refresh Token — een langlevend token waarmee nieuwe Access Tokens kunnen worden verkregen zonder dat de gebruiker opnieuw moet inloggen. Refresh Token wordt alleen bij de eerste login uitgegeven en kan door de gebruiker worden ingetrokken in de Google-accountinstellingen.

kotlin
// Voorbeeld van ID Token verwerking op de server (pseudocode)
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 en sessiebeheer

Beveiligingsaanbevelingen: stuur ID Token nooit via onbeveiligde kanalen, gebruik HTTPS voor alle verzoeken aan de server, controleer de geldigheidsduur van het token (veld exp) en issuer (iss). Sla tokens op de client niet op in SharedPreferences zonder versleuteling — gebruik EncryptedSharedPreferences of Android Keystore. Google Sign-In is niet bedoeld voor server-server authenticatie — hiervoor worden Service Accounts gebruikt.

Codevoorbeeld: Google Sign-In-integratie in Kotlin

Een volledig voorbeeld van Google Sign-In-integratie in een Android-app met Credential Manager en ViewModel. De app toont een inlogknop, stuurt na authenticatie de ID Token naar de server en toont gebruikersinformatie. De code gebruikt coroutines voor asynchroon werk met Credential Manager.

kotlin
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()
}

Na succesvolle authenticatie moet de app de ID Token naar zijn eigen server sturen voor verificatie en het creëren van een sessie. Het wordt aanbevolen HTTPS te gebruiken en het token in de body van een POST-verzoek te sturen. De server retourneert zijn eigen sessietoken, dat de client opslaat in EncryptedSharedPreferences. Bij elk volgend verzoek aan de server wordt het interne token gebruikt, niet de Google ID Token.

Veelvoorkomende fouten bij integratie en hun oplossingen

De eerste veelvoorkomende fout — niet-overeenkomende SHA-1 van het certificaat. Google Cloud Console koppelt OAuth 2.0 Client ID aan de SHA-1 vingerafdruk van het ondertekeningscertificaat. Als de app wordt gebouwd met een debug-sleutel maar de Client ID is gemaakt voor een release-sleutel, retourneert Google Sign-In fout 12501 (SIGN_IN_FAILED). Oplossing — voeg beide SHA-1 (debug en release) toe in Google Cloud Console of gebruik één Client ID voor ontwikkeling en een aparte voor productie.

Het tweede veelvoorkomende probleem — onjuiste serverClientId. Ontwikkelaars gebruiken vaak Android Client ID in plaats van de Client ID van de web-app in de parameter serverClientId van Credential Manager. Google vereist precies de web-client ID voor het genereren van ID Token bestemd voor serververificatie. Android Client ID wordt alleen gebruikt voor identificatie van de app in het authenticatieproces. Controleer of serverClientId overeenkomt met de web-app in Google Cloud Console.

De derde fout — het negeren van annuleringsafhandeling. De gebruiker kan het Google Sign-In dialoogvenster sluiten zonder de authenticatie te voltooien. Credential Manager gooit GetCredentialCancellationException, dat apart van andere fouten moet worden afgehandeld. Veel ontwikkelaars behandelen alle uitzonderingen als fouten en tonen de gebruiker het bericht “Inloggen mislukt”, terwijl de gebruiker simpelweg de operatie heeft geannuleerd. Juiste afhandeling: bij Cancelled — toon niets, keer gewoon terug naar de oorspronkelijke staat.

Veelgestelde vragen

Welke versie van Google Sign-In SDK gebruiken in 2026?

Het wordt aanbevolen Credential Manager (AndroidX Credentials) te gebruiken voor Android en GIDSignIn SDK via Swift Package Manager voor iOS. Credential Manager — een moderne API ondersteund door Google, die Google Sign-In, Passkeys en wachtwoordlogin combineert in één interface. De verouderde GoogleSignInClient (com.google.android.gms:auth) wordt niet meer aanbevolen voor gebruik.

Wat is het verschil tussen ID Token en Access Token in Google Sign-In?

ID Token — is een JWT met gebruikersinformatie (naam, e-mail, unieke ID). Wordt gebruikt voor authenticatie aan de serverzijde van de app. Access Token — een opaque string voor toegang tot Google API (Google Drive, Calendar). ID Token is 1 uur geldig, Access Token ook 1 uur, maar kan worden vernieuwd via Refresh Token.

Kan ik Google Sign-In gebruiken zonder serververificatie?

Technisch mogelijk, maar het is onveilig. Als u ID Token alleen op de client verifieert, kan een aanvaller de app decompileren en de verificatielogica extraheren. Serververificatie met behulp van openbare sleutels van Google garandeert dat het token daadwerkelijk door Google is uitgegeven en niet is vervalst. Gebruik voor apps zonder server Firebase Authentication.

Waarom retourneert Google Sign-In fout 12501?

Fout 12501 (SIGN_IN_FAILED) treedt op wanneer de SHA-1 van het app-certificaat niet overeenkomt met die in Google Cloud Console. Oplossing: voeg SHA-1 van het debug-certificaat (uit Android Studio) en het release-certificaat toe in de console. Controleer ook of de package name in de console overeenkomt met build.gradle. Na wijziging kan het tot 24 uur duren voordat het is doorgevoerd.

Ondersteunt Google Sign-In inloggen zonder internet?

Nee, Google Sign-In heeft een internetverbinding nodig voor communicatie met Google-servers. Als het apparaat offline is, gebruik dan een sessiecaching-mechanisme: na succesvol inloggen het token opslaan in EncryptedSharedPreferences en de geldigheid controleren bij de volgende start. Bij afwezigheid van netwerk toon opgeslagen gegevens en stel voor later in te loggen.

Samenvatting

  • Google Sign-In — SDK voor authenticatie via Google-account op basis van OAuth 2.0 en OpenID Connect
  • OAuth 2.0 — protocol waarbij de app een toegangstoken ontvangt zonder het wachtwoord van de gebruiker door te geven
  • Credential Manager — moderne Android API voor Google Sign-In met native Bottom Sheet en Passkeys-ondersteuning
  • ID Token — JWT met gebruikersgegevens die de server verifieert met openbare sleutels van Google
  • Beveiliging is gebaseerd op SHA-1 handtekening van de app, HTTPS en cryptografische JWT-verificatie
  • iOS-integratie vereist configuratie van URL Scheme, Keychain Sharing en GoogleSignIn SDK via Swift Package Manager
  • Veelvoorkomende fouten — SHA-1 mismatch, onjuiste serverClientId en het negeren van CancellationException

We ontwikkelen een mobiele applicatie turnkey

IT Sectr creëert sinds 2017 iOS- en Android-applicaties voor startups en bedrijven. We adviseren u en stellen de beste oplossing voor.

Bespreek het project

Lees ook