Google Sign-In é um SDK do Google que implementa a autenticação de usuários através de contas Google em aplicativos móveis e web. A tecnologia é baseada no protocolo OAuth 2.0, que permite obter tokens de acesso às APIs do Google sem transmitir a senha para um aplicativo de terceiros. Mais de 3 bilhões de dispositivos Android suportam o Google Sign-In, tornando-o o método de login mais comum em aplicativos móveis. De acordo com Google Identity Platform, 2025, a integração do SDK reduz o tempo de registro em 60% e aumenta a conversão de usuários.
Principais pontos
Google Sign-In é um serviço de login único (Single Sign-On) fornecido pelo Google para autenticação de usuários em aplicativos de terceiros. O SDK permite que desenvolvedores integrem o login através de uma conta Google sem precisar criar seu próprio sistema de registro. A tecnologia é baseada no protocolo OAuth 2.0 e OpenID Connect, fornecendo informações de identidade do usuário: nome, email, avatar e identificador único.
Ao contrário da autenticação tradicional por email e senha, o Google Sign-In elimina a necessidade de lembrar senhas e passar pelo procedimento de registro. O usuário seleciona uma conta Google no dispositivo, confirma as permissões e o aplicativo recebe um token de acesso. De acordo com Google Identity Platform (2025), aplicativos com Google Sign-In mostram 52% mais registros bem-sucedidos em comparação com formulários de email/senha.
O Google Sign-In suporta três cenários de uso: autenticação do usuário (obtenção de ID Token), autorização para acesso às APIs do Google (obtenção de Access Token) e autenticação sem interrupções (Silent Sign-In) para usuários já autorizados. Cada cenário requer um conjunto diferente de escopos (scopes) e retorna diferentes tipos de tokens.
OAuth 2.0 é um protocolo de autorização que permite que um aplicativo obtenha acesso limitado aos recursos do usuário sem revelar suas credenciais. No contexto do Google Sign-In, o protocolo funciona da seguinte forma: o aplicativo solicita autorização ao usuário através do Google, recebe um código de autorização temporário, troca-o por tokens de acesso e usa esses tokens para chamar as APIs do Google.
A principal diferença do OAuth 2.0 em relação aos protocolos anteriores é a separação de papéis entre o proprietário do recurso (usuário), o cliente (aplicativo), o servidor de autorização (Google) e o servidor de recursos (API do Google). O aplicativo nunca recebe a senha do usuário — apenas um token que pode ser revogado. O Google Identity Platform utiliza a especificação OpenID Connect sobre o OAuth 2.0, adicionando um ID Token padronizado no formato JWT.
// Exemplo de obtenção de 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) contém três segmentos: um cabeçalho com o algoritmo de assinatura, um payload com os dados do usuário (sub, email, name, picture) e uma assinatura para verificação. A parte do servidor do aplicativo verifica a assinatura do ID Token usando as chaves públicas do Google e extrai o identificador do usuário. Esta abordagem garante que mesmo que o aplicativo cliente seja comprometido, um invasor não pode falsificar o token sem acesso à chave privada do Google.
Credential Manager é uma API moderna do Android introduzida em 2023 que combina todos os métodos de autenticação (Google Sign-In, login com senha, Passkeys) em uma única interface de usuário. Ao contrário do antigo GoogleSignInClient, o Credential Manager não requer WebView para login — ele usa um Bottom Sheet nativo, o que acelera a autenticação e melhora a experiência do usuário.
A principal vantagem do Credential Manager é uma experiência de usuário unificada para todos os tipos de credenciais. O usuário vê uma única caixa de diálogo onde pode escolher: entrar com Google, usar uma Passkey ou digitar uma senha. O desenvolvedor não precisa gerenciar diferentes fluxos de autenticação — o Credential Manager abstrai a interação com Google Sign-In, Smart Lock e Passkeys. O Google recomenda o Credential Manager como a principal forma de integrar o Google Sign-In para Android 14+.
| Parâmetro | GoogleSignInClient (legado) | Credential Manager |
|---|---|---|
| API mínima | Android 4.4 (API 19) | Android 4.4 (API 19) |
| Interface | WebView / BottomSheet | BottomSheet nativo |
| Suporte a Passkeys | Não | Sim |
| Tamanho do SDK | ~500 KB | ~150 KB |
| Status | Obsoleto (2024) | Recomendado pelo Google |
Migração do GoogleSignInClient para o Credential Manager requer alteração da lógica do cliente: em vez de GoogleSignInOptions, use GoogleIdCredentialOption, e em vez de GoogleSignIn.getSignedInAccountFromIntent, processe o resultado através de GetCredentialResponse. A parte do servidor não requer alterações, pois o ID Token mantém o mesmo formato JWT. De acordo com o Google I/O 2024, cerca de 40% dos aplicativos na Google Play já migraram para o Credential Manager.
A integração do Google Sign-In em um aplicativo Android começa com a configuração do projeto no Google Cloud Console. O primeiro passo é criar um Client ID OAuth 2.0 para Android: especificar o package name do aplicativo e a impressão digital do certificado SHA-1. O Google usa esses dados para verificar se a solicitação de autenticação vem do seu aplicativo e não de um cliente falso.
Após criar o cliente no Google Cloud Console, o desenvolvedor adiciona a dependência do Credential Manager ao build.gradle e configura o GoogleIdCredentialOption com serverClientId. Importante: serverClientId é o Client ID do aplicativo web do mesmo projeto do Google Cloud, que o servidor usa para verificar o ID Token. O aplicativo cliente não verifica o token — ele apenas o recebe e o encaminha para o 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 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
}Após receber o ID Token no cliente, o aplicativo o envia para seu servidor onde a verificação é realizada. O servidor verifica a assinatura do JWT usando as chaves públicas do Google (disponíveis em https://www.googleapis.com/oauth2/v3/certs), o tempo de expiração do token (exp) e o valor do campo aud — deve corresponder ao serverClientId. Após a verificação, o servidor cria sua própria sessão, por exemplo, emitindo um JWT interno ou Session Token.
A integração do Google Sign-In no iOS é feita através do SDK GoogleSignIn-iOS, disponível via CocoaPods ou Swift Package Manager. O processo de configuração inclui criar um Client ID para iOS no Google Cloud Console (especificando o Bundle Identifier), adicionar um URL Scheme para callback e configurar o AppDelegate para manipular a URL retornada pelo Google após a autenticação.
Uma diferença importante da versão iOS do Google Sign-In em relação ao Android é a necessidade de configurar URL Scheme e Info.plist. O GoogleSDK usa Universal Links para callback, mas como fallback, é necessário um URL Scheme no formato `com.googleusercontent.apps.[CLIENT_ID]`. Também é necessária a configuração de Keychain Sharing para salvar o refresh token entre as inicializações do aplicativo. De acordo com a documentação do Google Identity, o SDK do iOS suporta iOS 15 e superior.
// Configuração do Google Sign-In no 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 para o servidor
sendTokenToBackend(idToken)
}
}
}No iOS, o Google Sign-In suporta Silent Sign-In para usuários que autorizaram anteriormente. O método restorePreviousSignIn restaura automaticamente a sessão se o refresh token estiver salvo no Keychain. Isso é especialmente importante para aplicativos onde o usuário não deve fazer login novamente a cada inicialização. De acordo com o Google, o Silent Sign-In é bem-sucedido em 85% dos casos em dispositivos com sessão ativa do Google.
Segurança do Google Sign-In é construída em três níveis: verificação do cliente (assinatura SHA-1 do aplicativo), criptografia de transporte (HTTPS/TLS) e assinatura criptográfica JWT. O ID Token recebido do Google é assinado usando o algoritmo RS256 (RSA com SHA-256). A parte do servidor do aplicativo deve verificar a assinatura do token, a expiração e o emissor (iss) — apenas accounts.google.com.
Access Token é um token temporário (vive 1 hora) que fornece acesso às APIs do Google (Google Drive, Google Calendar, YouTube, etc.). Ao contrário do ID Token, o Access Token não contém informações do usuário — é uma string opaca que o servidor da API do Google usa para autorização de solicitações. Refresh Token é um token de longa duração que permite obter novos Access Tokens sem que o usuário faça login novamente. O Refresh Token é emitido apenas no primeiro login e pode ser revogado pelo usuário nas configurações da conta Google.
// Exemplo de processamento de ID Token no servidor (pseudocó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
)
}Recomendações de segurança: nunca transmita o ID Token por canais não seguros, use HTTPS para todas as solicitações ao servidor, verifique a expiração do token (campo exp) e o emissor (iss). No cliente, não armazene tokens em SharedPreferences sem criptografia — use EncryptedSharedPreferences ou Android Keystore. Google Sign-In não foi projetado para autenticação servidor a servidor — para isso, use Service Accounts.
Um exemplo completo de integração do Google Sign-In em um aplicativo Android usando Credential Manager e ViewModel. O aplicativo exibe um botão de login, após a autenticação envia o ID Token para o servidor e mostra as informações do usuário. O código usa corrotinas para trabalho assíncrono com o 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()
}Após a autenticação bem-sucedida, o aplicativo deve enviar o ID Token para seu servidor para verificação e criação de sessão. Recomenda-se usar HTTPS e passar o token no corpo da solicitação POST. O servidor retorna seu próprio token de sessão, que o cliente armazena em EncryptedSharedPreferences. Em cada solicitação subsequente ao servidor, o token interno é usado, não o ID Token do Google.
O primeiro erro comum é a incompatibilidade do certificado SHA-1. O Google Cloud Console vincula o Client ID OAuth 2.0 à impressão digital do certificado SHA-1. Se o aplicativo for compilado com uma chave de depuração, mas o Client ID foi criado para uma chave de release, o Google Sign-In retornará o erro 12501 (SIGN_IN_FAILED). Solução: adicione ambas as impressões digitais SHA-1 (depuração e release) no Google Cloud Console ou use um Client ID para desenvolvimento e outro separado para produção.
O segundo problema frequente é um serverClientId incorreto. Os desenvolvedores costumam usar o Client ID do Android em vez do Client ID do aplicativo web no parâmetro serverClientId do Credential Manager. O Google exige exatamente o Client ID web para gerar o ID Token destinado à verificação do servidor. O Client ID do Android é usado apenas para identificar o aplicativo durante a autenticação. Certifique-se de que o serverClientId corresponda ao aplicativo web no Google Cloud Console.
O terceiro erro é ignorar o tratamento de cancelamento. O usuário pode fechar a caixa de diálogo do Google Sign-In sem concluir a autenticação. O Credential Manager lança uma GetCredentialCancellationException que precisa ser tratada separadamente de outros erros. Muitos desenvolvedores tratam todas as exceções como erros, mostrando ao usuário uma mensagem de “Falha no login” quando o usuário simplesmente cancelou a operação. Tratamento correto: em caso de cancelamento — não mostre nada, apenas retorne ao estado inicial.
Perguntas frequentes
Recomenda-se usar Credential Manager (AndroidX Credentials) para Android e o SDK GIDSignIn via Swift Package Manager para iOS. O Credential Manager é uma API moderna compatível com o Google que combina Google Sign-In, Passkeys e login por senha em uma única interface. O obsoleto GoogleSignInClient (com.google.android.gms:auth) não é mais recomendado.
ID Token é um JWT contendo informações do usuário (nome, email, ID único). É usado para autenticação no lado do servidor do aplicativo. Access Token é uma string opaca para acessar as APIs do Google (Google Drive, Calendar). O ID Token vive 1 hora, o Access Token também vive 1 hora, mas pode ser renovado através de um Refresh Token.
Tecnicamente sim, mas não é seguro. Se você verificar o ID Token apenas no cliente, um invasor pode descompilar o aplicativo e extrair a lógica de verificação. A verificação do lado do servidor usando as chaves públicas do Google garante que o token foi realmente emitido pelo Google e não foi falsificado. Para aplicativos sem servidor, use o Firebase Authentication.
O erro 12501 (SIGN_IN_FAILED) ocorre quando o certificado SHA-1 do aplicativo não corresponde ao especificado no Google Cloud Console. Solução: adicione o SHA-1 do certificado de depuração (do Android Studio) e do certificado de release no console. Verifique também se o package name no console corresponde ao build.gradle. Após a alteração, pode levar até 24 horas para propagar.
Não, o Google Sign-In requer conexão com a internet para se comunicar com os servidores do Google. Se o dispositivo estiver offline, use um mecanismo de cache de sessão: após o login bem-sucedido, salve o token em EncryptedSharedPreferences e verifique sua validade na próxima inicialização. Quando não houver rede, mostre os dados salvos e sugira fazer login mais tarde.
Resumo
Vamos desenvolver um aplicativo móvel chave na mão
A IT Sectr cria aplicativos para iOS e Android para startups e empresas desde 2017. Nós vamos aconselhá-lo e propor a melhor solução.
Leia também