Theory
Log in with an account you already have
Making users invent yet another password is friction; many will not bother. Google Sign-In removes it: users log in to FestConnect with their existing Google account, tapping to choose it rather than creating new credentials.
This is federated authentication, the user proves who they are to Google, and Firebase trusts that. This lesson shows the flow and the one new idea it introduces: exchanging a Google token for a Firebase credential. It is a pattern you will reuse for Facebook and other providers, so learn it once here.
Theory
The federated flow
Google Sign-In works in a few steps:
1. Your app launches the Google sign-in flow.
2. The user picks their Google account (and approves, if first time).
3. Google returns a Google ID token, proof that Google authenticated this user.
4. Your app wraps that token as a Firebase credential with GoogleAuthProvider.getCredential(idToken, null).
5. You call auth.signInWithCredential(credential), and Firebase signs the user in.
After that, the user is a normal FirebaseUser (currentUser is set), exactly as with email/password, just authenticated through Google. You also enable Google as a provider in the Firebase console first.
Practical
Exchanging the Google token for a Firebase sign-in
// After the Google sign-in flow returns a Google ID token:
val credential = GoogleAuthProvider.getCredential(idToken, null)
Firebase.auth.signInWithCredential(credential)
.addOnCompleteListener { task ->
if (task.isSuccessful) {
val user = Firebase.auth.currentUser // signed in via Google
} else {
// handle task.exception
}
}
// The user never created a password for your app; Google vouched for them.Formula
The token-to-credential pattern
The heart of every federated sign-in is the same: the provider (Google) authenticates the user and gives you a token; you turn that token into a Firebase credential and call signInWithCredential.
For Google it is GoogleAuthProvider.getCredential(...); for Facebook (next lesson) it will be FacebookAuthProvider.getCredential(...). The rest, signInWithCredential and the resulting FirebaseUser, is identical. So once you understand 'get a token from the provider, exchange it for a Firebase credential', you understand all federated logins. That shared shape is why Firebase can support many providers cleanly.
Quiz
In Google Sign-In with Firebase, what do you do with the Google ID token your app receives?
- Store it as the user's password
- Wrap it as a Firebase credential (GoogleAuthProvider.getCredential) and call signInWithCredential to sign the user into Firebase
- Email it to the user
- Ignore it; Firebase does not need it
Show the answer
Wrap it as a Firebase credential (GoogleAuthProvider.getCredential) and call signInWithCredential to sign the user into Firebase
The Google ID token is proof that Google authenticated the user; you convert it into a Firebase credential with GoogleAuthProvider.getCredential(idToken, null) and pass that to auth.signInWithCredential(...), which signs the user into Firebase. Option A is wrong: the token is not a password to store; it is a one-time proof of identity exchanged for a Firebase sign-in. Option C makes no sense; the token is used programmatically, not emailed. Option D is wrong: the token is exactly what Firebase needs to complete the federated sign-in, ignoring it would mean the user never gets signed in. The pattern: provider token -> Firebase credential -> signInWithCredential.
Think first
Why let users sign in with Google instead of making them create a password?
What do users and developers gain from federated sign-in like Google? Then tap.
Show the answer
Both sides gain CONVENIENCE and SECURITY, because the user reuses a trusted account they already have instead of creating and managing yet another password. For the USER: signing up becomes a single tap to choose their Google account, no new password to invent, remember, or later reset, which dramatically lowers the friction of getting started (many people abandon sign-ups that demand a new account). They also trust Google to guard their credentials, and they get Google's protections (like strong passwords and two-factor authentication) for free on your app. For the DEVELOPER and app: you never handle or store that user's password at all, Google authenticates them and vouches for them, so there is one less sensitive credential in your system to protect, and one less attack surface. You also tend to get reliable profile information (verified email, name) from the provider. The trade-offs: you depend on the provider, and some users prefer not to link accounts, which is why apps usually offer BOTH federated options (Google, Facebook) AND plain email/password, letting each user choose. Federated sign-in is popular precisely because it makes onboarding almost effortless while improving security, a rare win-win, which is why offering 'Sign in with Google' is standard practice in modern apps. Reuse a trusted identity: easier for users, safer for you.
Summary
Key takeaways
- Google Sign-In is federated authentication: the user logs in with their existing Google account, not a password in your app.
- Flow: launch Google sign-in, user picks an account, you receive a Google ID token.
- Wrap the token as a Firebase credential with GoogleAuthProvider.getCredential(idToken, null).
- Call auth.signInWithCredential(credential); on success the user is a normal FirebaseUser.
- Enable Google as a provider in the Firebase console first.
- The token-to-credential pattern is shared by all federated providers (Facebook uses FacebookAuthProvider the same way).
- Memory hook: provider gives a token, exchange it for a Firebase credential, signInWithCredential.