Google Sign-In : ce que c’est, connexion avec Google et SDK OAuth 2.0

Qu’est-ce que Google Sign-In ?

Google Sign-In est un service d’authentification unique (Single Sign-On) fourni par Google pour l’authentification des utilisateurs dans les applications tierces. Le SDK permet aux développeurs d’intégrer la connexion via un compte Google sans avoir à créer leur propre système d’inscription. La technologie est basée sur le protocole OAuth 2.0 et OpenID Connect, fournissant les informations d’identité de l’utilisateur : nom, e-mail, avatar et identifiant unique.

Contrairement à l’authentification traditionnelle par e-mail et mot de passe, Google Sign-In élimine la nécessité de mémoriser les mots de passe et de passer par la procédure d’inscription. L’utilisateur sélectionne un compte Google sur l’appareil, confirme les autorisations et l’application reçoit un jeton d’accès. Selon Google Identity Platform (2025), les applications avec Google Sign-In affichent 52% d’inscriptions réussies de plus que les formulaires e-mail/mot de passe.

Google Sign-In prend en charge trois scénarios d’utilisation : authentification utilisateur (obtention d’un ID Token), autorisation d’accès aux API Google (obtention d’un Access Token) et authentification transparente (Silent Sign-In) pour les utilisateurs déjà autorisés. Chaque scénario nécessite un ensemble différent de périmètres (scopes) et retourne différents types de jetons.

Comment fonctionne OAuth 2.0 dans Google Sign-In

OAuth 2.0 est un protocole d’autorisation qui permet à une application d’obtenir un accès limité aux ressources de l’utilisateur sans divulguer ses informations d’identification. Dans le contexte de Google Sign-In, le protocole fonctionne comme suit : l’application demande l’autorisation à l’utilisateur via Google, reçoit un code d’autorisation temporaire, l’échange contre des jetons d’accès et utilise ces jetons pour appeler les API Google.

La différence clé de OAuth 2.0 par rapport aux protocoles antérieurs est la séparation des rôles entre le propriétaire de la ressource (utilisateur), le client (application), le serveur d’autorisation (Google) et le serveur de ressources (API Google). L’application ne reçoit jamais le mot de passe de l’utilisateur — seulement un jeton qui peut être révoqué. Google Identity Platform utilise la spécification OpenID Connect au-dessus d’OAuth 2.0, ajoutant un ID Token standardisé au format JWT.

ID Token vs Access Token : différences

// Exemple d’obtention d’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) contient trois segments : un en-tête avec l’algorithme de signature, un payload avec les données utilisateur (sub, email, name, picture) et une signature pour la vérification. La partie serveur de l’application vérifie la signature de l’ID Token à l’aide des clés publiques de Google et extrait l’identifiant de l’utilisateur. Cette approche garantit que même si l’application cliente est compromise, un attaquant ne peut pas falsifier le jeton sans accéder à la clé privée de Google.

Credential Manager : nouvelle méthode de connexion sur Android

Credential Manager est une API Android moderne introduite en 2023 qui combine toutes les méthodes d’authentification (Google Sign-In, connexion par mot de passe, Passkeys) en une seule interface utilisateur. Contrairement à l’ancien GoogleSignInClient, Credential Manager ne nécessite pas de WebView pour la connexion — il utilise une Bottom Sheet native, ce qui accélère l’authentification et améliore l’expérience utilisateur.

Le principal avantage de Credential Manager est une expérience utilisateur unifiée pour tous les types d’informations d’identification. L’utilisateur voit une seule boîte de dialogue où il peut choisir : se connecter avec Google, utiliser un Passkey ou saisir un mot de passe. Le développeur n’a pas besoin de gérer différents flux d’authentification — Credential Manager abstrait l’interaction avec Google Sign-In, Smart Lock et Passkeys. Google recommande Credential Manager comme méthode principale d’intégration de Google Sign-In pour Android 14+.

Migration de GoogleSignInClient vers Credential Manager

Migration de GoogleSignInClient vers Credential Manager nécessite de modifier la logique côté client : au lieu de GoogleSignInOptions, utilisez GoogleIdCredentialOption, et au lieu de GoogleSignIn.getSignedInAccountFromIntent, traitez le résultat via GetCredentialResponse. La partie serveur ne nécessite pas de modifications car l’ID Token conserve le même format JWT. Selon Google I/O 2024, environ 40% des applications sur Google Play ont déjà migré vers Credential Manager.

Configurer Google Sign-In dans un projet Android

L’intégration de Google Sign-In dans une application Android commence par la configuration du projet dans Google Cloud Console. La première étape consiste à créer un ID client OAuth 2.0 pour Android : spécifiez le nom du package de l’application et l’empreinte du certificat SHA-1. Google utilise ces données pour vérifier que la demande d’authentification provient de votre application et non d’un client frauduleux.

Après avoir créé le client dans Google Cloud Console, le développeur ajoute la dépendance Credential Manager au build.gradle et configure GoogleIdCredentialOption avec serverClientId. Important : serverClientId est l’ID client de l’application web du même projet Google Cloud, que le serveur utilise pour vérifier l’ID Token. L’application cliente ne vérifie pas le jeton — elle le reçoit seulement et le transmet au serveur.

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

// Demander 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
}

Après avoir reçu l’ID Token sur le client, l’application l’envoie à son serveur où la vérification est effectuée. Le serveur vérifie la signature JWT à l’aide des clés publiques de Google (disponibles sur https://www.googleapis.com/oauth2/v3/certs), la date d’expiration du jeton (exp) et la valeur du champ aud — elle doit correspondre à serverClientId. Après vérification, le serveur crée sa propre session, par exemple en émettant un JWT interne ou un Session Token.

Google Sign-In sur iOS : configuration et spécificités

L’intégration de Google Sign-In sur iOS se fait via le SDK GoogleSignIn-iOS, disponible via CocoaPods ou Swift Package Manager. Le processus de configuration comprend la création d’un ID client pour iOS dans Google Cloud Console (en spécifiant le Bundle Identifier), l’ajout d’un URL Scheme pour le rappel et la configuration d’AppDelegate pour gérer l’URL retournée par Google après l’authentification.

Une différence importante de la version iOS de Google Sign-In par rapport à Android est la nécessité de configurer URL Scheme et Info.plist. GoogleSDK utilise Universal Links pour le rappel, mais pour le fallback, un URL Scheme de la forme `com.googleusercontent.apps.[CLIENT_ID]` est requis. La configuration de Keychain Sharing est également nécessaire pour conserver le refresh token entre les lancements de l’application. Selon la documentation Google Identity, le SDK iOS prend en charge iOS 15 et versions ultérieures.

// Configuration de Google Sign-In sur 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
            // Envoi de l’ID Token au serveur
            sendTokenToBackend(idToken)
        }
    }
}

Sur iOS, Google Sign-In prend en charge Silent Sign-In pour les utilisateurs qui ont déjà autorisé. La méthode restorePreviousSignIn restaure automatiquement la session si le refresh token est enregistré dans le Keychain. Ceci est particulièrement important pour les applications où l’utilisateur ne doit pas se reconnecter à chaque lancement. Selon Google, Silent Sign-In réussit dans 85% des cas sur les appareils avec une session Google active.

Gestion des jetons et sécurité

Sécurité de Google Sign-In repose sur trois niveaux : vérification client (signature SHA-1 de l’application), chiffrement du transport (HTTPS/TLS) et signature cryptographique JWT. L’ID Token reçu de Google est signé avec l’algorithme RS256 (RSA avec SHA-256). La partie serveur de l’application doit vérifier la signature du jeton, l’expiration et l’émetteur (iss) — uniquement accounts.google.com.

Access Token est un jeton temporaire (durée de vie 1 heure) qui donne accès aux API Google (Google Drive, Google Calendar, YouTube, etc.). Contrairement à l’ID Token, l’Access Token ne contient pas d’informations utilisateur — c’est une chaîne opaque que le serveur d’API Google utilise pour l’autorisation des requêtes. Refresh Token est un jeton de longue durée qui permet d’obtenir de nouveaux Access Tokens sans que l’utilisateur se reconnecte. Le Refresh Token est émis uniquement lors de la première connexion et peut être révoqué par l’utilisateur dans les paramètres de son compte Google.

// Exemple de traitement d’ID Token sur le serveur (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 et gestion de session

Recommandations de sécurité : ne transmettez jamais l’ID Token via des canaux non sécurisés, utilisez HTTPS pour toutes les requêtes au serveur, vérifiez l’expiration du jeton (champ exp) et l’émetteur (iss). Côté client, ne stockez pas les jetons dans SharedPreferences sans chiffrement — utilisez EncryptedSharedPreferences ou Android Keystore. Google Sign-In n’est pas conçu pour l’authentification serveur-à-serveur — utilisez Service Accounts pour cela.

Exemple de code : intégration de Google Sign-In en Kotlin

Un exemple complet d’intégration de Google Sign-In dans une application Android utilisant Credential Manager et ViewModel. L’application affiche un bouton de connexion, après l’authentification envoie l’ID Token au serveur et affiche les informations de l’utilisateur. Le code utilise des coroutines pour le travail asynchrone avec 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()
}

Après une authentification réussie, l’application doit envoyer l’ID Token à son serveur pour vérification et création de session. Il est recommandé d’utiliser HTTPS et de passer le jeton dans le corps de la requête POST. Le serveur renvoie son propre jeton de session, que le client stocke dans EncryptedSharedPreferences. À chaque requête suivante au serveur, le jeton interne est utilisé, pas l’ID Token Google.

Erreurs fréquentes d’intégration et solutions

La première erreur courante est la non-concordance du certificat SHA-1. Google Cloud Console lie l’ID client OAuth 2.0 à l’empreinte du certificat SHA-1. Si l’application est compilée avec une clé de débogage mais que l’ID client a été créé pour une clé de release, Google Sign-In renverra l’erreur 12501 (SIGN_IN_FAILED). Solution : ajoutez les deux empreintes SHA-1 (débogage et release) dans Google Cloud Console ou utilisez un ID client pour le développement et un autre séparé pour la production.

Le deuxième problème fréquent est un serverClientId incorrect. Les développeurs utilisent souvent l’ID client Android au lieu de l’ID client de l’application web dans le paramètre serverClientId de Credential Manager. Google exige exactement l’ID client web pour générer l’ID Token destiné à la vérification serveur. L’ID client Android est utilisé uniquement pour identifier l’application lors de l’authentification. Vérifiez que serverClientId correspond à l’application web dans Google Cloud Console.

La troisième erreur est l’ignorance de la gestion d’annulation. L’utilisateur peut fermer la boîte de dialogue Google Sign-In sans terminer l’authentification. Credential Manager lance une GetCredentialCancellationException qui doit être traitée séparément des autres erreurs. De nombreux développeurs traitent toutes les exceptions comme des erreurs, affichant à l’utilisateur un message « Échec de connexion » alors que l’utilisateur a simplement annulé l’opération. Traitement correct : en cas d’annulation — n’affichez rien, revenez simplement à l’état initial.