Google Sign-In: Was es ist, Google-Login und OAuth 2.0 SDK

Was ist Google Sign-In?

Google Sign-In ist ein Single Sign-On-Dienst (SSO) von Google zur Benutzerauthentifizierung in Drittanwendungen. Das SDK ermöglicht Entwicklern die Integration des Logins über ein Google-Konto, ohne ein eigenes Registrierungssystem erstellen zu müssen. Die Technologie basiert auf dem OAuth 2.0-Protokoll und OpenID Connect und liefert Benutzeridentitätsinformationen: Name, E-Mail, Avatar und eindeutige Kennung.

Im Gegensatz zur herkömmlichen Authentifizierung per E-Mail und Passwort entfällt bei Google Sign-In die Notwendigkeit, sich Passwörter zu merken und durch das Registrierungsverfahren zu gehen. Der Benutzer wählt ein Google-Konto auf dem Gerät aus, bestätigt die Berechtigungen und die App erhält ein Zugriffstoken. Laut Google Identity Platform (2025) zeigen Apps mit Google Sign-In 52% mehr erfolgreiche Registrierungen im Vergleich zu E-Mail/Passwort-Formularen.

Google Sign-In unterstützt drei Nutzungsszenarien: Benutzerauthentifizierung (Erhalt eines ID Tokens), Autorisierung für den Zugriff auf Google-APIs (Erhalt eines Access Tokens) und nahtlose Authentifizierung (Silent Sign-In) für bereits autorisierte Benutzer. Jedes Szenario erfordert einen anderen Umfang (Scopes) und gibt verschiedene Token-Typen zurück.

Wie OAuth 2.0 in Google Sign-In funktioniert

OAuth 2.0 ist ein Autorisierungsprotokoll, das einer App einen eingeschränkten Zugriff auf Benutzerressourcen ermöglicht, ohne deren Anmeldeinformationen preiszugeben. Im Kontext von Google Sign-In funktioniert das Protokoll wie folgt: Die App fordert vom Benutzer eine Autorisierung über Google an, erhält einen temporären Autorisierungscode, tauscht ihn gegen Zugriffstokens aus und verwendet diese Tokens, um Google-APIs aufzurufen.

Der Hauptunterschied von OAuth 2.0 zu früheren Protokollen ist die Trennung der Rollen zwischen dem Ressourceninhaber (Benutzer), dem Client (App), dem Autorisierungsserver (Google) und dem Ressourcenserver (Google-API). Die App erhält niemals das Passwort des Benutzers — nur ein Token, das widerrufen werden kann. Google Identity Platform verwendet die OpenID Connect-Spezifikation auf OAuth 2.0 und fügt ein standardisiertes ID Token im JWT-Format hinzu.

ID Token vs Access Token: Unterschiede

// Beispiel für den Erhalt eines ID Tokens über den 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) enthält drei Segmente: einen Header mit dem Signaturalgorithmus, einen Payload mit Benutzerdaten (sub, email, name, picture) und eine Signatur zur Verifizierung. Der serverseitige Teil der App überprüft die ID Token-Signatur mit den öffentlichen Schlüsseln von Google und extrahiert die Benutzerkennung. Dieser Ansatz garantiert, dass selbst wenn die Client-App kompromittiert ist, ein Angreifer das Token ohne Zugriff auf den privaten Schlüssel von Google nicht fälschen kann.

Credential Manager: Neue Anmeldemethode auf Android

Credential Manager ist eine moderne Android-API, die 2023 eingeführt wurde und alle Authentifizierungsmethoden (Google Sign-In, Passwort-Login, Passkeys) in einer einzigen Benutzeroberfläche vereint. Im Gegensatz zum alten GoogleSignInClient benötigt der Credential Manager kein WebView für die Anmeldung — er verwendet ein natives Bottom Sheet, was die Authentifizierung beschleunigt und die Benutzererfahrung verbessert.

Der Hauptvorteil von Credential Manager ist eine einheitliche Benutzererfahrung für alle Anmeldeinformationstypen. Der Benutzer sieht einen Dialog, in dem er wählen kann: Mit Google anmelden, einen Passkey verwenden oder ein Passwort eingeben. Der Entwickler muss keine verschiedenen Authentifizierungsabläufe verwalten — der Credential Manager abstrahiert die Interaktion mit Google Sign-In, Smart Lock und Passkeys. Google empfiehlt den Credential Manager als primäre Methode zur Integration von Google Sign-In für Android 14+.

Migration von GoogleSignInClient zu Credential Manager

Migration von GoogleSignInClient zu Credential Manager erfordert eine Änderung der Client-Logik: Statt GoogleSignInOptions verwenden Sie GoogleIdCredentialOption, und statt GoogleSignIn.getSignedInAccountFromIntent verarbeiten Sie das Ergebnis über GetCredentialResponse. Der serverseitige Teil erfordert keine Änderungen, da das ID Token dasselbe JWT-Format beibehält. Laut Google I/O 2024 sind bereits etwa 40% der Apps im Google Play auf Credential Manager migriert.

Google Sign-In in einem Android-Projekt einrichten

Die Integration von Google Sign-In in eine Android-App beginnt mit der Konfiguration des Projekts in der Google Cloud Console. Der erste Schritt ist die Erstellung einer OAuth 2.0-Client-ID für Android: Geben Sie den Paketnamen der App und den SHA-1-Zertifikatsfingerabdruck an. Google verwendet diese Daten, um zu überprüfen, dass die Authentifizierungsanforderung von Ihrer App und nicht von einem gefälschten Client stammt.

Nach der Erstellung des Clients in der Google Cloud Console fügt der Entwickler die Credential Manager-Abhängigkeit zu build.gradle hinzu und konfiguriert GoogleIdCredentialOption mit serverClientId. Wichtig: serverClientId ist die Client-ID der Webanwendung aus demselben Google Cloud-Projekt, die der Server zur Überprüfung des ID Tokens verwendet. Die Client-App überprüft das Token nicht — sie empfängt es nur und leitet es an den Server weiter.

// 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 über den Credential Manager anfordern
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
}

Nach Erhalt des ID Tokens auf dem Client sendet die App es an ihren Server, wo die Verifizierung durchgeführt wird. Der Server überprüft die JWT-Signatur mit den öffentlichen Schlüsseln von Google (verfügbar unter https://www.googleapis.com/oauth2/v3/certs), die Token-Ablaufzeit (exp) und den Wert des aud-Felds — es muss mit serverClientId übereinstimmen. Nach der Verifizierung erstellt der Server seine eigene Sitzung, z.B. durch Ausstellung eines internen JWT oder Session Tokens.

Google Sign-In auf iOS: Einrichtung und Funktionen

Die Integration von Google Sign-In auf iOS erfolgt über das GoogleSignIn-iOS SDK, verfügbar über CocoaPods oder Swift Package Manager. Der Einrichtungsprozess umfasst die Erstellung einer Client-ID für iOS in der Google Cloud Console (mit Angabe der Bundle-ID), das Hinzufügen eines URL-Schemas für den Rückruf und die Konfiguration des AppDelegate zur Verarbeitung der von Google nach der Authentifizierung zurückgegebenen URL.

Ein wichtiger Unterschied der iOS-Version von Google Sign-In zu Android ist die Notwendigkeit, URL-Schema und Info.plist zu konfigurieren. GoogleSDK verwendet Universal Links für den Rückruf, aber für den Fallback ist ein URL-Schema der Form `com.googleusercontent.apps.[CLIENT_ID]` erforderlich. Auch die Keychain Sharing-Konfiguration ist erforderlich, um das Refresh-Token zwischen App-Starts zu speichern. Laut Google Identity-Dokumentation unterstützt das iOS SDK iOS 15 und höher.

// Google Sign-In auf iOS einrichten
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 an den Server senden
            sendTokenToBackend(idToken)
        }
    }
}

Unter iOS unterstützt Google Sign-In Silent Sign-In für Benutzer, die zuvor autorisiert wurden. Die Methode restorePreviousSignIn stellt die Sitzung automatisch wieder her, wenn das Refresh-Token in der Keychain gespeichert ist. Dies ist besonders wichtig für Apps, bei denen der Benutzer nicht bei jedem Start erneut anmelden soll. Laut Google ist Silent Sign-In in 85% der Fälle auf Geräten mit aktiver Google-Sitzung erfolgreich.

Token-Verwaltung und Sicherheit

Sicherheit von Google Sign-In basiert auf drei Ebenen: Client-Verifizierung (SHA-1-App-Signatur), Transportverschlüsselung (HTTPS/TLS) und kryptografische JWT-Signatur. Das von Google erhaltene ID Token wird mit dem RS256-Algorithmus (RSA mit SHA-256) signiert. Der serverseitige Teil der App muss die Tokensignatur, den Ablauf und den Aussteller (iss) überprüfen — nur accounts.google.com.

Access Token ist ein temporäres Token (Lebensdauer 1 Stunde), das Zugriff auf Google-APIs (Google Drive, Google Calendar, YouTube usw.) ermöglicht. Im Gegensatz zum ID Token enthält das Access Token keine Benutzerinformationen — es ist eine undurchsichtige Zeichenfolge, die der Google-API-Server zur Autorisierung von Anfragen verwendet. Refresh Token ist ein langlebiges Token, mit dem neue Access Tokens ohne erneute Anmeldung des Benutzers abgerufen werden können. Das Refresh Token wird nur bei der ersten Anmeldung ausgestellt und kann vom Benutzer in den Google-Kontoeinstellungen widerrufen werden.

// Beispiel für die Verarbeitung von ID Token auf dem 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 und Sitzungsverwaltung

Sicherheitsempfehlungen: Übertragen Sie das ID Token niemals über ungesicherte Kanäle, verwenden Sie HTTPS für alle Serveranfragen, überprüfen Sie den Token-Ablauf (Feld exp) und den Aussteller (iss). Speichern Sie Tokens auf dem Client nicht unverschlüsselt in SharedPreferences — verwenden Sie EncryptedSharedPreferences oder Android Keystore. Google Sign-In ist nicht für die Server-zu-Server-Authentifizierung vorgesehen — verwenden Sie dafür Service Accounts.

Codebeispiel: Google Sign-In-Integration in Kotlin

Ein vollständiges Beispiel zur Integration von Google Sign-In in eine Android-App mit Credential Manager und ViewModel. Die App zeigt einen Anmeldebutton an, sendet nach der Authentifizierung das ID Token an den Server und zeigt Benutzerinformationen an. Der Code verwendet Koroutinen für die asynchrone Arbeit mit dem 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()
}

Nach erfolgreicher Authentifizierung sollte die App das ID Token zur Verifizierung und Sitzungserstellung an ihren Server senden. Es wird empfohlen, HTTPS zu verwenden und das Token im Body der POST-Anfrage zu übergeben. Der Server gibt sein eigenes Sitzungstoken zurück, das der Client in EncryptedSharedPreferences speichert. Bei jeder nachfolgenden Anfrage an den Server wird das interne Token verwendet, nicht das Google-ID-Token.

Häufige Integrationsfehler und Lösungen

Der erste häufige Fehler ist die Nichtübereinstimmung des SHA-1-Zertifikats. Die Google Cloud Console bindet die OAuth 2.0-Client-ID an den SHA-1-Zertifikatsfingerabdruck. Wenn die App mit einem Debug-Schlüssel erstellt wurde, die Client-ID jedoch für einen Release-Schlüssel erstellt wurde, gibt Google Sign-In den Fehler 12501 (SIGN_IN_FAILED) zurück. Lösung: Fügen Sie beide SHA-1-Fingerabdrücke (Debug und Release) in der Google Cloud Console hinzu oder verwenden Sie eine Client-ID für die Entwicklung und eine separate für die Produktion.

Das zweite häufige Problem ist eine falsche serverClientId. Entwickler verwenden häufig die Android-Client-ID anstelle der Webanwendungs-Client-ID im Parameter serverClientId des Credential Managers. Google benötigt genau die Web-Client-ID für die Generierung des ID Tokens, das für die Server-Verifizierung bestimmt ist. Die Android-Client-ID wird nur zur Identifizierung der App während der Authentifizierung verwendet. Stellen Sie sicher, dass serverClientId mit der Webanwendung in der Google Cloud Console übereinstimmt.

Der dritte Fehler ist das Ignorieren der Abbruchbehandlung. Der Benutzer kann den Google Sign-In-Dialog schließen, ohne die Authentifizierung abzuschließen. Der Credential Manager wirft eine GetCredentialCancellationException, die getrennt von anderen Fehlern behandelt werden muss. Viele Entwickler behandeln alle Ausnahmen als Fehler und zeigen dem Benutzer eine „Anmeldung fehlgeschlagen“-Meldung an, obwohl der Benutzer den Vorgang lediglich abgebrochen hat. Korrekte Handhabung: Bei Abbruch — nichts anzeigen, einfach in den Ausgangszustand zurückkehren.