Google Sign-In: qué es, inicio de sesión con Google y SDK OAuth 2.0

¿Qué es Google Sign-In?

Google Sign-In es un servicio de inicio de sesión único (Single Sign-On) proporcionado por Google para la autenticación de usuarios en aplicaciones de terceros. El SDK permite a los desarrolladores integrar el inicio de sesión a través de una cuenta de Google sin tener que crear su propio sistema de registro. La tecnología se basa en el protocolo OAuth 2.0 y OpenID Connect, proporcionando información de identidad del usuario: nombre, correo electrónico, avatar e identificador único.

A diferencia de la autenticación tradicional por correo electrónico y contraseña, Google Sign-In elimina la necesidad de recordar contraseñas y pasar por el procedimiento de registro. El usuario selecciona una cuenta de Google en el dispositivo, confirma los permisos y la aplicación recibe un token de acceso. Según Google Identity Platform (2025), las aplicaciones con Google Sign-In muestran un 52% más de registros exitosos en comparación con los formularios de correo/contraseña.

Google Sign-In admite tres escenarios de uso: autenticación de usuario (obtención de ID Token), autorización para acceder a las API de Google (obtención de Access Token) y autenticación sin interrupciones (Silent Sign-In) para usuarios ya autorizados. Cada escenario requiere un conjunto diferente de ámbitos (scopes) y devuelve diferentes tipos de tokens.

Cómo funciona OAuth 2.0 en Google Sign-In

OAuth 2.0 es un protocolo de autorización que permite a una aplicación obtener acceso limitado a los recursos del usuario sin revelar sus credenciales. En el contexto de Google Sign-In, el protocolo funciona de la siguiente manera: la aplicación solicita autorización al usuario a través de Google, recibe un código de autorización temporal, lo intercambia por tokens de acceso y utiliza esos tokens para llamar a las API de Google.

La diferencia clave de OAuth 2.0 con respecto a protocolos anteriores es la separación de roles entre el propietario del recurso (usuario), el cliente (aplicación), el servidor de autorización (Google) y el servidor de recursos (API de Google). La aplicación nunca recibe la contraseña del usuario, solo un token que puede revocarse. Google Identity Platform utiliza la especificación OpenID Connect sobre OAuth 2.0, añadiendo un ID Token estandarizado en formato JWT.

ID Token vs Access Token: diferencias

// Ejemplo de obtención de ID Token mediante 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) contiene tres segmentos: un encabezado con el algoritmo de firma, un payload con los datos del usuario (sub, email, name, picture) y una firma para verificación. La parte del servidor de la aplicación verifica la firma del ID Token utilizando las claves públicas de Google y extrae el identificador del usuario. Este enfoque garantiza que incluso si la aplicación cliente se ve comprometida, un atacante no puede falsificar el token sin acceso a la clave privada de Google.

Credential Manager: nuevo método de inicio de sesión en Android

Credential Manager es una API moderna de Android introducida en 2023 que combina todos los métodos de autenticación (Google Sign-In, inicio de sesión con contraseña, Passkeys) en una única interfaz de usuario. A diferencia del antiguo GoogleSignInClient, Credential Manager no requiere WebView para iniciar sesión — utiliza un Bottom Sheet nativo, lo que acelera la autenticación y mejora la experiencia del usuario.

La principal ventaja de Credential Manager es una experiencia de usuario unificada para todos los tipos de credenciales. El usuario ve un solo diálogo donde puede elegir: iniciar sesión con Google, usar una Passkey o introducir una contraseña. El desarrollador no necesita gestionar diferentes flujos de autenticación — Credential Manager abstrae la interacción con Google Sign-In, Smart Lock y Passkeys. Google recomienda Credential Manager como la forma principal de integrar Google Sign-In para Android 14+.

Migración de GoogleSignInClient a Credential Manager

Migración de GoogleSignInClient a Credential Manager requiere cambiar la lógica del cliente: en lugar de GoogleSignInOptions, se usa GoogleIdCredentialOption, y en lugar de GoogleSignIn.getSignedInAccountFromIntent, se procesa el resultado a través de GetCredentialResponse. La parte del servidor no requiere cambios ya que el ID Token mantiene el mismo formato JWT. Según Google I/O 2024, aproximadamente el 40% de las aplicaciones en Google Play ya han migrado a Credential Manager.

Configurar Google Sign-In en un proyecto Android

La integración de Google Sign-In en una aplicación Android comienza con la configuración del proyecto en Google Cloud Console. El primer paso es crear un Client ID de OAuth 2.0 para Android: especificar el package name de la aplicación y la huella digital del certificado SHA-1. Google utiliza estos datos para verificar que la solicitud de autenticación proviene de su aplicación y no de un cliente falso.

Después de crear el cliente en Google Cloud Console, el desarrollador agrega la dependencia de Credential Manager en build.gradle y configura GoogleIdCredentialOption con serverClientId. Importante: serverClientId es el Client ID de la aplicación web del mismo proyecto de Google Cloud, que el servidor utiliza para verificar el ID Token. La aplicación cliente no verifica el token — solo lo recibe y lo envía al servidor.

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

// Solicitar Google Sign-In mediante 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
}

Después de recibir el ID Token en el cliente, la aplicación lo envía a su servidor donde se realiza la verificación. El servidor verifica la firma del JWT utilizando las claves públicas de Google (disponibles en https://www.googleapis.com/oauth2/v3/certs), el tiempo de expiración del token (exp) y el valor del campo aud — debe coincidir con serverClientId. Después de la verificación, el servidor crea su propia sesión, por ejemplo, emitiendo un JWT interno o un Session Token.

Google Sign-In en iOS: configuración y características

La integración de Google Sign-In en iOS se realiza a través del SDK GoogleSignIn-iOS, disponible mediante CocoaPods o Swift Package Manager. El proceso de configuración incluye la creación de un Client ID para iOS en Google Cloud Console (especificando el Bundle Identifier), la adición de un URL Scheme para la devolución de llamada y la configuración de AppDelegate para manejar la URL devuelta por Google después de la autenticación.

Una diferencia importante de la versión iOS de Google Sign-In respecto a Android es la necesidad de configurar URL Scheme e Info.plist. GoogleSDK utiliza Universal Links para la devolución de llamada, pero como respaldo se requiere un URL Scheme de la forma `com.googleusercontent.apps.[CLIENT_ID]`. También se requiere la configuración de Keychain Sharing para guardar el refresh token entre los inicios de la aplicación. Según la documentación de Google Identity, el SDK de iOS es compatible con iOS 15 y superior.

// Configuración de Google Sign-In en 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
            // Enviar ID Token al servidor
            sendTokenToBackend(idToken)
        }
    }
}

En iOS, Google Sign-In admite Silent Sign-In para usuarios que se han autorizado previamente. El método restorePreviousSignIn restaura automáticamente la sesión si el refresh token está guardado en Keychain. Esto es especialmente importante para aplicaciones donde el usuario no debe volver a iniciar sesión en cada inicio. Según Google, Silent Sign-In tiene éxito en el 85% de los casos en dispositivos con una sesión activa de Google.

Gestión de tokens y seguridad

Seguridad de Google Sign-In se basa en tres niveles: verificación del cliente (firma SHA-1 de la aplicación), cifrado de transporte (HTTPS/TLS) y firma criptográfica JWT. El ID Token recibido de Google está firmado con el algoritmo RS256 (RSA con SHA-256). La parte del servidor de la aplicación debe verificar la firma del token, la fecha de expiración y el emisor (iss) — solo accounts.google.com.

Access Token es un token temporal (vive 1 hora) que proporciona acceso a las API de Google (Google Drive, Google Calendar, YouTube, etc.). A diferencia del ID Token, el Access Token no contiene información del usuario — es una cadena opaca que el servidor de la API de Google utiliza para la autorización de solicitudes. Refresh Token es un token de larga duración que permite obtener nuevos Access Tokens sin que el usuario vuelva a iniciar sesión. El Refresh Token se emite solo en el primer inicio de sesión y puede ser revocado por el usuario en la configuración de su cuenta de Google.

// Ejemplo de procesamiento de ID Token en el servidor (seudocódigo)
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 y gestión de sesión

Recomendaciones de seguridad: nunca transmita el ID Token a través de canales no seguros, use HTTPS para todas las solicitudes al servidor, verifique la fecha de expiración del token (campo exp) y el emisor (iss). En el cliente, no almacene tokens en SharedPreferences sin cifrado — use EncryptedSharedPreferences o Android Keystore. Google Sign-In no está diseñado para autenticación servidor a servidor — para eso use Service Accounts.

Ejemplo de código: integración de Google Sign-In en Kotlin

Un ejemplo completo de integración de Google Sign-In en una aplicación Android usando Credential Manager y ViewModel. La aplicación muestra un botón de inicio de sesión, después de la autenticación envía el ID Token al servidor y muestra la información del usuario. El código utiliza corutinas para el trabajo asíncrono con 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()
}

Después de una autenticación exitosa, la aplicación debe enviar el ID Token a su servidor para su verificación y creación de sesión. Se recomienda usar HTTPS y pasar el token en el cuerpo de la solicitud POST. El servidor devuelve su propio token de sesión, que el cliente guarda en EncryptedSharedPreferences. En cada solicitud posterior al servidor, se utiliza el token interno, no el ID Token de Google.

Errores comunes en la integración y sus soluciones

El primer error común es la falta de coincidencia del certificado SHA-1. Google Cloud Console vincula el Client ID de OAuth 2.0 a la huella digital del certificado SHA-1. Si la aplicación se compila con una clave de depuración pero el Client ID se creó para una clave de lanzamiento, Google Sign-In devolverá el error 12501 (SIGN_IN_FAILED). Solución: agregue ambas huellas SHA-1 (depuración y lanzamiento) en Google Cloud Console o use un Client ID para desarrollo y otro separado para producción.

El segundo problema frecuente es un serverClientId incorrecto. Los desarrolladores suelen usar el Client ID de Android en lugar del Client ID de la aplicación web en el parámetro serverClientId de Credential Manager. Google requiere exactamente el Client ID web para generar el ID Token destinado a la verificación del servidor. El Client ID de Android se usa solo para identificar la aplicación durante la autenticación. Asegúrese de que serverClientId coincida con la aplicación web en Google Cloud Console.

El tercer error es ignorar la gestión de cancelación. El usuario puede cerrar el diálogo de Google Sign-In sin completar la autenticación. Credential Manager lanza una excepción GetCredentialCancellationException que debe manejarse por separado de otros errores. Muchos desarrolladores manejan todas las excepciones como errores, mostrando al usuario un mensaje de “Inicio de sesión fallido” cuando el usuario simplemente canceló la operación. Manejo correcto: en caso de cancelación, no mostrar nada, simplemente volver al estado inicial.