Theory
The same idea, a different provider
Having done Google Sign-In, Facebook Sign-In will feel familiar, because it follows the same federated pattern. The user logs in with their Facebook account, Facebook vouches for them, and Firebase signs them in.
The only real difference is the provider: you use the Facebook Login SDK to get a token, and the FacebookAuthProvider to wrap it. Everything else, signInWithCredential and the resulting FirebaseUser, is identical to Google. This short lesson highlights that shared shape, which is the key insight for adding any federated provider.
Theory
The Facebook flow
The steps mirror Google:
1. Your app uses the Facebook Login SDK (LoginManager) to log the user in via Facebook.
2. On success, you receive a Facebook access token.
3. You wrap it as a Firebase credential with FacebookAuthProvider.getCredential(token.token).
4. You call auth.signInWithCredential(credential), and Firebase signs the user in.
As before, you first configure a Facebook app (to get an app id) and enable Facebook as a provider in the Firebase console. After sign-in, the user is a normal FirebaseUser, no matter which provider got them there.
Practical
Facebook token to Firebase sign-in
// After the Facebook Login SDK returns an AccessToken 'token':
val credential = FacebookAuthProvider.getCredential(token.token)
Firebase.auth.signInWithCredential(credential)
.addOnCompleteListener { task ->
if (task.isSuccessful) {
val user = Firebase.auth.currentUser // signed in via Facebook
} else {
// handle task.exception
}
}
// Compare with Google: only GoogleAuthProvider -> FacebookAuthProvider changed.Formula
One pattern, many providers
Look how little changed from Google to Facebook: the SDK that produces the token differs, and the provider class differs (FacebookAuthProvider instead of GoogleAuthProvider), but the exchange, getCredential then signInWithCredential, is exactly the same.
This is the payoff of Firebase's design: every federated login reduces to 'get a token from the provider, turn it into a Firebase credential, sign in'. Learn it once, and adding Facebook, Twitter/X, GitHub, or others is mostly configuration plus swapping the provider. The consistent pattern is what makes supporting many login options practical.
Quiz
How does Facebook Sign-In with Firebase differ from Google Sign-In?
- It uses a completely different mechanism with no tokens
- It follows the same token-to-credential pattern; you use the Facebook SDK and FacebookAuthProvider, then the same signInWithCredential
- It does not need a Firebase project
- It stores the Facebook password in your app
Show the answer
It follows the same token-to-credential pattern; you use the Facebook SDK and FacebookAuthProvider, then the same signInWithCredential
Facebook Sign-In uses the SAME federated pattern as Google: the Facebook Login SDK authenticates the user and returns an access token, you wrap it with FacebookAuthProvider.getCredential(...), and call the same auth.signInWithCredential(...). Only the provider SDK and the provider class change. Option A is wrong: it very much uses a token (a Facebook access token), just as Google uses an ID token. Option C is wrong: it still needs a Firebase project with Facebook enabled as a provider. Option D is false and unsafe: your app never receives or stores the user's Facebook password; Facebook authenticates them and returns a token. Same pattern, different provider.
Think first
Why is it valuable that all federated providers share one pattern?
Google and Facebook (and others) all reduce to the same steps. Why does that consistency matter to you as a developer? Then tap.
Show the answer
Because a single, consistent pattern means you LEARN ONCE and REUSE everywhere, which keeps your code simple, your effort low, and your app easy to extend, a big practical advantage. If every sign-in provider had its own completely different way of integrating with Firebase, adding each one would be a fresh research-and-debug project, and your codebase would fill with divergent, hard-to-maintain flows. Instead, Firebase deliberately funnels them all through the same shape: the provider authenticates the user and yields a token, you convert the token to a Firebase credential via that provider's AuthProvider class, and you call the one method signInWithCredential. So once you have done Google, doing Facebook is mostly configuration (set up the Facebook app, enable the provider) plus swapping GoogleAuthProvider for FacebookAuthProvider; the sign-in logic and everything after it (the FirebaseUser, your app's screens, your database rules) are unchanged. This lets you offer users several login choices cheaply, and add more later without rearchitecting. It also means your knowledge transfers: understanding one federated login means understanding them all. This is the same design virtue you keep meeting, a stable interface (Firebase sign-in) behind interchangeable implementations (the providers), and it is precisely what makes 'sign in with X' so easy to add across modern apps. Learn the pattern, reuse it for every provider.
Summary
Key takeaways
- Facebook Sign-In is federated authentication following the same pattern as Google.
- The Facebook Login SDK logs the user in and returns a Facebook access token.
- Wrap the token as a Firebase credential with FacebookAuthProvider.getCredential(token.token).
- Call auth.signInWithCredential(credential); on success the user is a normal FirebaseUser.
- Configure a Facebook app and enable Facebook as a provider in the Firebase console first.
- Only the provider SDK and provider class differ from Google; getCredential and signInWithCredential are identical.
- Memory hook: same token-to-credential pattern, just FacebookAuthProvider instead of GoogleAuthProvider.