Theory
The cast of Firebase Auth
Before writing login code, it helps to know the main players in Firebase Authentication, because the same few classes appear in every auth feature you build.
There are four to know: FirebaseAuth (the service you call), FirebaseUser (the signed-in user), provider classes (which sign-in method), and AuthUI (a ready-made sign-in screen). This lesson introduces each and how they fit together, so the detailed auth lessons that follow read easily. Learn the cast, and the plot is simple.
At a glance
| Class | Role |
|---|---|
| FirebaseAuth | The authentication service you call (sign in/out, get current user) |
| FirebaseUser | Represents the signed-in user (uid, email, display name) |
| Provider classes | Identify the sign-in method: EmailAuthProvider, GoogleAuthProvider, FacebookAuthProvider |
| AuthUI (FirebaseUI) | A prebuilt, drop-in sign-in screen supporting multiple providers |
Theory
FirebaseAuth and FirebaseUser
FirebaseAuth is the heart of it: the instance through which you sign users in, sign them out, and check who is signed in. You get it with Firebase.auth (or FirebaseAuth.getInstance()).
FirebaseUser represents the currently signed-in person, carrying details like their unique uid, email, and display name. You reach it with auth.currentUser, which is null when nobody is signed in. That single check, is currentUser null or not, is how your app knows whether to show the login screen or the main app. FirebaseAuth is the service; FirebaseUser is who is using it.
Practical
FirebaseAuth and the current user
val auth = Firebase.auth // the FirebaseAuth service
val user = auth.currentUser // FirebaseUser, or null
if (user != null) {
println("Signed in as ${user.email} (uid ${user.uid})")
} else {
println("Not signed in - show the login screen")
}
auth.signOut() // sign the user outFormula
Providers name the method; AuthUI offers a ready screen
The provider classes say HOW someone signs in. EmailAuthProvider is email and password; GoogleAuthProvider is Google Sign-In; FacebookAuthProvider is Facebook. Each supplies the credential for its method, which you then hand to FirebaseAuth.
AuthUI, from the FirebaseUI library, is different: it is a ready-made sign-in screen that already knows how to show and handle whichever providers you enable, so you get a working login flow with almost no UI code. So you have a choice: use AuthUI's prebuilt screen, or call FirebaseAuth directly with a provider and your own UI, the very choice the next two lessons explore.
Quiz
In Firebase Authentication, what does auth.currentUser return when nobody is signed in?
- An empty FirebaseAuth object
- null, indicating no user is currently signed in (otherwise it is a FirebaseUser)
- The last user who ever signed in
- An error that crashes the app
Show the answer
null, indicating no user is currently signed in (otherwise it is a FirebaseUser)
auth.currentUser returns the signed-in FirebaseUser, or null when nobody is signed in, so a null check is how the app decides whether to show the login screen or the main content. Option A confuses the classes: currentUser is a FirebaseUser (the user), not a FirebaseAuth (the service), and it is null when absent, not an 'empty' service object. Option C is wrong: once signed out, currentUser is null, it does not linger as the previous user. Option D is wrong: reading currentUser does not crash; returning null is the normal, expected way to signal 'not signed in'. Check currentUser for null to know the sign-in state.
Think first
Why separate the provider from FirebaseAuth itself?
Why does Firebase use separate provider classes rather than baking each sign-in method into FirebaseAuth directly? Then tap.
Show the answer
Because separating the METHOD of proving identity (the provider) from the SERVICE that manages authentication (FirebaseAuth) keeps the design flexible and extensible, one service can support many sign-in methods without changing. Think about what varies and what stays the same. What VARIES is how a user proves who they are: email and password, a Google account, a Facebook account, a phone number, each has its own flow and produces its own kind of credential. What STAYS THE SAME is the rest: once identity is proven, the app has a signed-in FirebaseUser, checks currentUser, signs out, and so on, all handled by FirebaseAuth regardless of how the user signed in. By modelling each method as a separate PROVIDER that yields a credential, and letting FirebaseAuth accept any credential, Firebase cleanly separates these concerns. That means adding a new sign-in method (say, phone or Apple) is just another provider; it does not require rewriting FirebaseAuth or the code that uses currentUser. It also means your app can offer SEVERAL sign-in options that all funnel into the same FirebaseUser and the same downstream logic. This is a classic application of separating a stable interface (the auth service and its user) from interchangeable strategies (the providers), the same design thinking you have seen elsewhere, and it is why Firebase can support a growing list of sign-in methods so smoothly. Many ways in, one consistent signed-in user.
Summary
Key takeaways
- Firebase Authentication centres on a few classes that appear across every auth feature.
- FirebaseAuth is the service you call (sign in/out, check the current user); get it with Firebase.auth.
- FirebaseUser represents the signed-in user (uid, email, display name); auth.currentUser is null if nobody is signed in.
- Provider classes name the sign-in method: EmailAuthProvider, GoogleAuthProvider, FacebookAuthProvider.
- AuthUI (from FirebaseUI) is a prebuilt, drop-in sign-in screen supporting multiple providers.
- You can use AuthUI's ready screen or call FirebaseAuth directly with a provider and your own UI.
- Memory hook: FirebaseAuth the service, FirebaseUser the user, providers the methods, AuthUI the ready-made screen.