Firebase Authentication in Kotlin Android Apps
Building authentication in an Android app can feel like one of those tasks that looks small at the start and then quietly grows legs. At first, it seems simple: let people sign up, let them log in, and keep them inside the app. But once you start thinking about passwords, session handling, email verification, reset flows, social login, error states, loading states, and security, the picture becomes much bigger. That is exactly why Firebase Authentication has become such a popular choice for Kotlin Android apps. It removes much of the heavy lifting while still giving you a professional, secure, and scalable foundation.
What makes Firebase Authentication especially attractive is the balance it offers. You do not need to build an entire authentication backend from scratch just to ship a clean user experience. At the same time, you are not trapped in a rigid setup that forces you to compromise on the app structure you want. With Kotlin, Android developers can build beautiful authentication flows using Firebase for the identity layer and then focus their energy on the parts that truly make the app useful and delightful.
In this article, we will go far beyond a basic tutorial. We will walk through Firebase Authentication in Kotlin Android apps from the ground up, starting with the setup and moving through email/password login, registration, password reset, email verification, sign out, session management, and Google sign-in. We will also look at better code organization, error handling, user experience details, and practical advice that makes the difference between a demo and a real application. The goal is not only to make authentication work, but to make it feel trustworthy, polished, and human.
Why Firebase Authentication is a strong choice
Authentication is one of those features that users rarely praise when it works, but immediately notice when it fails. A slow login screen, confusing error messages, a password reset email that never arrives, or a sign-in method that behaves differently on each device can quickly damage trust. Firebase Authentication helps avoid many of these issues by providing a reliable, production-ready identity service that handles the core flows for you.
Another reason developers like Firebase Authentication is that it supports multiple sign-in methods. You can use email and password, phone authentication, anonymous access, Google, Facebook, GitHub, and more. That flexibility matters because not every app needs the same login style. A productivity app may be fine with email/password, while a consumer app may benefit from faster Google sign-in. Firebase gives you room to evolve without rewriting the entire authentication system later.
The Kotlin and Android ecosystem also pair nicely with Firebase. Firebase’s SDKs integrate smoothly into Android projects, and Kotlin makes it easier to write concise, readable code around asynchronous operations and UI state changes. Whether you are using Activities, Fragments, ViewModels, or a modern architecture with Jetpack Compose, Firebase Authentication can fit in with relatively little friction.
Most importantly, Firebase Authentication gives developers peace of mind. Security mistakes in authentication can be expensive, painful, and very hard to fix after launch. By relying on a mature service, you reduce the chances of reinventing something poorly. That does not mean you can ignore security entirely. It means you can build on a solid base instead of starting from an uncertain one.
Setting up Firebase in your Kotlin Android project
Before writing any login code, you need to connect your Android app to Firebase. This setup is usually straightforward, but it is worth doing carefully because a small configuration mistake can create hours of frustration later.
First, create or open your project in the Firebase console and add an Android app. You will need your app’s package name. After registering the app, download the google-services.json file and place it inside the app/ directory of your Android project. This file is what lets the Android app talk to Firebase correctly.
Next, make sure your project is configured for Firebase. In a modern Gradle setup, you usually add the Google services plugin and the authentication dependency. The exact syntax can differ slightly depending on whether you use Kotlin DSL or Groovy, but the idea is the same: enable Firebase services and bring in the Auth library.
Here is an example using Kotlin DSL-style Gradle configuration:
// Project-level build.gradle.kts
plugins {
id("com.android.application") version "8.0.0" apply false
id("org.jetbrains.kotlin.android") version "1.9.0" apply false
id("com.google.gms.google-services") version "4.4.0" apply false
}
// App-level build.gradle.kts
plugins {
id("com.android.application")
id("org.jetbrains.kotlin.android")
id("com.google.gms.google-services")
}
android {
namespace = "com.example.firebaseauth"
compileSdk = 34
defaultConfig {
applicationId = "com.example.firebaseauth"
minSdk = 24
targetSdk = 34
versionCode = 1
versionName = "1.0"
}
}
dependencies {
implementation(platform("com.google.firebase:firebase-bom:33.1.2"))
implementation("com.google.firebase:firebase-auth-ktx")
}
Once the dependency is added, sync your project. After that, FirebaseAuth becomes available in your app and you can start building the authentication flow.
Initializing Firebase Authentication in Kotlin
The basic Firebase Authentication instance is easy to create. In most apps, you will use Firebase.auth or FirebaseAuth.getInstance().
import com.google.firebase.auth.FirebaseAuth
import com.google.firebase.auth.ktx.auth
import com.google.firebase.ktx.Firebase
val auth: FirebaseAuth = Firebase.auth
This object is the entry point for most authentication operations. You will use it to create users, sign them in, sign them out, send password reset emails, and observe whether a user is currently logged in.
A very important thing to understand early is that Firebase Authentication does not magically replace your app’s UI logic. It handles identity, but you still need to manage screen transitions, validation, loading indicators, error messages, and the overall user experience. A good authentication flow is not only secure. It is also calm, clear, and predictable.
Creating a registration screen
A common starting point is email and password registration. This flow is still widely used because it is simple, familiar, and dependable. You ask the user for an email address and a password, then create an account in Firebase.
A polished registration screen should do more than just collect raw input. It should validate email formatting, require a strong enough password, confirm that the user accepts terms if needed, and show a loading state while the network request runs. That may sound like a lot, but in practice it is the difference between a rough prototype and a real app.
Here is a simple registration example:
import androidx.appcompat.app.AppCompatActivity
import android.os.Bundle
import android.widget.Toast
import com.google.firebase.auth.FirebaseAuth
class RegisterActivity : AppCompatActivity() {
private lateinit var auth: FirebaseAuth
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_register)
auth = FirebaseAuth.getInstance()
val emailInput = findViewById<android.widget.EditText>(R.id.emailInput)
val passwordInput = findViewById<android.widget.EditText>(R.id.passwordInput)
val registerButton = findViewById<android.widget.Button>(R.id.registerButton)
registerButton.setOnClickListener {
val email = emailInput.text.toString().trim()
val password = passwordInput.text.toString().trim()
if (email.isEmpty()) {
Toast.makeText(this, "Email is required", Toast.LENGTH_SHORT).show()
return@setOnClickListener
}
if (password.length < 6) {
Toast.makeText(this, "Password must be at least 6 characters", Toast.LENGTH_SHORT).show()
return@setOnClickListener
}
auth.createUserWithEmailAndPassword(email, password)
.addOnCompleteListener(this) { task ->
if (task.isSuccessful) {
Toast.makeText(this, "Registration successful", Toast.LENGTH_SHORT).show()
} else {
Toast.makeText(
this,
task.exception?.localizedMessage ?: "Registration failed",
Toast.LENGTH_LONG
).show()
}
}
}
}
}
This example is intentionally simple, but the structure is useful. Validate locally before making the network call, then handle success and failure cleanly. In a real application, you would likely move this logic into a ViewModel or repository so that your Activity or Compose screen stays focused on presentation rather than business logic.
Signing in with email and password
Once a user has an account, logging in is straightforward. Firebase provides signInWithEmailAndPassword, and the result tells you whether authentication succeeded.
auth.signInWithEmailAndPassword(email, password)
.addOnCompleteListener(this) { task ->
if (task.isSuccessful) {
Toast.makeText(this, "Welcome back!", Toast.LENGTH_SHORT).show()
// Navigate to home screen
} else {
Toast.makeText(
this,
task.exception?.localizedMessage ?: "Login failed",
Toast.LENGTH_LONG
).show()
}
}
A good login screen does not just authenticate and move on. It also helps the user recover from failure. If the password is wrong, the error message should be understandable. If the email does not exist, the user should not feel like they hit a dead end. Human-friendly authentication means designing for the moments when people are tired, distracted, or rushing.
You can also check whether there is already a signed-in user when the app opens. This is useful because returning users should not need to log in again every time unless they explicitly signed out.
val currentUser = FirebaseAuth.getInstance().currentUser
if (currentUser != null) {
// User is already signed in
// Navigate directly to the main screen
} else {
// Show login screen
}
That small check often becomes the heart of your app’s launch logic.
Watching the authentication state
In real apps, authentication state can change at any moment. The user may sign in, sign out, or the app may restore a session after being reopened. Firebase provides an authentication state listener that helps you respond to those changes.
private lateinit var auth: FirebaseAuth
private lateinit var authStateListener: FirebaseAuth.AuthStateListener
override fun onStart() {
super.onStart()
auth.addAuthStateListener(authStateListener)
}
override fun onStop() {
super.onStop()
auth.removeAuthStateListener(authStateListener)
}
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
auth = FirebaseAuth.getInstance()
authStateListener = FirebaseAuth.AuthStateListener { firebaseAuth ->
val user = firebaseAuth.currentUser
if (user != null) {
// User is signed in
} else {
// User is signed out
}
}
}
This is especially useful when you need your app to react automatically instead of manually checking the auth status in several places. A user who is signed in should see a different path than a user who is not. That sounds obvious, but many apps become messy when authentication logic is duplicated in too many screens. One listener, one clear source of truth, fewer surprises.
Email verification and why it matters
Many apps register accounts immediately without verifying the user’s email first. That can work, but in most cases it is better to verify the email address before granting full access. Verification reduces fake accounts, helps users recover accounts later, and adds another layer of trust.
Firebase makes it easy to send a verification email after account creation.
val user = FirebaseAuth.getInstance().currentUser
user?.sendEmailVerification()
?.addOnCompleteListener { task ->
if (task.isSuccessful) {
Toast.makeText(this, "Verification email sent", Toast.LENGTH_LONG).show()
} else {
Toast.makeText(
this,
task.exception?.localizedMessage ?: "Failed to send verification email",
Toast.LENGTH_LONG
).show()
}
}
After the user clicks the verification link, you can reload the user and check whether the email is verified.
val user = FirebaseAuth.getInstance().currentUser
user?.reload()?.addOnCompleteListener {
if (user.isEmailVerified) {
// Allow access to verified-only features
} else {
// Ask user to verify email
}
}
The reason this matters is not only technical. It changes the tone of the app. Verification tells the user that the account is real, secure, and worth protecting. That extra step can feel reassuring rather than annoying when it is explained clearly.
Password reset flow
People forget passwords. That is not a failure of the user. It is a normal part of human behavior, and the login flow should treat it that way. Firebase Authentication supports password reset emails through a simple API.
auth.sendPasswordResetEmail(email)
.addOnCompleteListener { task ->
if (task.isSuccessful) {
Toast.makeText(this, "Password reset email sent", Toast.LENGTH_LONG).show()
} else {
Toast.makeText(
this,
task.exception?.localizedMessage ?: "Could not send reset email",
Toast.LENGTH_LONG
).show()
}
}
The best password reset screen is calm and direct. It should not shame the user. It should simply say, “Enter your email and we will send you instructions.” That kind of language keeps the experience respectful and reduces friction. Security is important, but user dignity matters too.
Signing out
Sign-out is often overlooked because it is so simple, but it is a crucial part of session control. In Firebase, signing out is a single line.
FirebaseAuth.getInstance().signOut()
After that, the current user becomes null, and your auth state logic should send the user back to the login screen or onboarding flow. This is one of the reasons it is helpful to centralize auth-state checking. When sign-out happens, the rest of your app should respond naturally without you having to patch several screens.
A more organized approach with a repository
As your app grows, you may notice that Firebase code begins to appear in multiple places. That can quickly get messy. A cleaner architecture is to wrap Firebase Authentication in a repository or service layer. This way, your UI does not know too much about how authentication works internally.
Here is a simple repository example:
import com.google.firebase.auth.FirebaseAuth
import com.google.firebase.auth.FirebaseUser
import kotlinx.coroutines.tasks.await
class AuthRepository(
private val auth: FirebaseAuth = FirebaseAuth.getInstance()
) {
suspend fun register(email: String, password: String): Result<FirebaseUser?> {
return try {
val result = auth.createUserWithEmailAndPassword(email, password).await()
Result.success(result.user)
} catch (e: Exception) {
Result.failure(e)
}
}
suspend fun login(email: String, password: String): Result<FirebaseUser?> {
return try {
val result = auth.signInWithEmailAndPassword(email, password).await()
Result.success(result.user)
} catch (e: Exception) {
Result.failure(e)
}
}
fun logout() {
auth.signOut()
}
fun currentUser(): FirebaseUser? {
return auth.currentUser
}
}
This pattern gives you a few nice benefits. It keeps Firebase calls in one place. It makes testing easier. It makes future changes easier too, because if you ever decide to alter your login logic, you only have one layer to update.
To use await() in coroutines, you need the appropriate task extension dependency. This is a strong choice when you are building Kotlin-first Android apps because coroutines are cleaner than deeply nested callbacks.
implementation("org.jetbrains.kotlinx:kotlinx-coroutines-play-services:1.8.1")
Using coroutines for cleaner code
Callback-based code works, but Kotlin shines when you use coroutines. With coroutines, your authentication logic becomes easier to read and maintain. Compare the callback style with a suspending function, and the difference becomes obvious.
import com.google.firebase.auth.FirebaseAuth
import kotlinx.coroutines.tasks.await
class FirebaseAuthService(
private val auth: FirebaseAuth = FirebaseAuth.getInstance()
) {
suspend fun login(email: String, password: String): Boolean {
return try {
auth.signInWithEmailAndPassword(email, password).await()
true
} catch (e: Exception) {
false
}
}
}
Then in your ViewModel:
import androidx.lifecycle.ViewModel
import androidx.lifecycle.viewModelScope
import kotlinx.coroutines.launch
class LoginViewModel(
private val authService: FirebaseAuthService = FirebaseAuthService()
) : ViewModel() {
fun login(email: String, password: String, onResult: (Boolean) -> Unit) {
viewModelScope.launch {
val success = authService.login(email, password)
onResult(success)
}
}
}
This style keeps the UI clean and makes your code easier to reason about. It also becomes much easier to show loading states because you know exactly when an operation starts and ends.
Google sign-in with Firebase Authentication
Email and password are useful, but many users prefer a faster experience. Google sign-in reduces typing, improves conversion, and often feels more natural on Android because many users already have a Google account on the device. Firebase Authentication supports Google sign-in, though the setup has a few more moving parts than email/password.
At a high level, the process works like this: you sign the user into Google, retrieve the ID token, and pass that token to Firebase to complete the authentication. The exact setup includes Google Cloud configuration, SHA-1 or SHA-256 fingerprint registration, enabling Google as a sign-in provider in Firebase, and wiring the Google Identity API into your Android app.
The code below shows the Firebase side of the flow after you have obtained the Google account and ID token:
import com.google.firebase.auth.GoogleAuthProvider
import com.google.firebase.auth.FirebaseAuth
fun firebaseAuthWithGoogle(idToken: String) {
val credential = GoogleAuthProvider.getCredential(idToken, null)
FirebaseAuth.getInstance().signInWithCredential(credential)
.addOnCompleteListener { task ->
if (task.isSuccessful) {
// Google sign-in success
} else {
// Handle error
}
}
}
Google sign-in feels valuable because it removes a lot of friction at the most sensitive moment in the app journey: first access. When users can enter quickly, they are much more likely to reach the part of the app that matters.
Handling authentication errors properly
A mature authentication flow is not defined by success alone. It is defined by how gracefully it handles failure. Authentication errors are common, and every one of them deserves a clear response. The user may type the wrong password, the email may already exist, the network may be down, or the account may be disabled.
Firebase throws exceptions that you can inspect and translate into friendlier messages. That translation layer is important because raw exception messages often feel technical or intimidating.
private fun getFriendlyErrorMessage(exception: Exception?): String {
return when (exception) {
is com.google.firebase.auth.FirebaseAuthInvalidUserException -> "No account found for this email."
is com.google.firebase.auth.FirebaseAuthInvalidCredentialsException -> "The email or password is incorrect."
is com.google.firebase.auth.FirebaseAuthUserCollisionException -> "This email is already registered."
else -> exception?.localizedMessage ?: "Something went wrong. Please try again."
}
}
Then use it in your login or registration callback:
auth.signInWithEmailAndPassword(email, password)
.addOnCompleteListener { task ->
if (task.isSuccessful) {
// success
} else {
val message = getFriendlyErrorMessage(task.exception)
Toast.makeText(this, message, Toast.LENGTH_LONG).show()
}
}
This kind of improvement may seem small, but it can dramatically improve how users feel about your app. People are often willing to forgive a failed attempt if the app explains the problem clearly. Confusion is what creates frustration.
Building a better user experience around authentication
Authentication is not only about APIs. It is about the emotional experience of entering your app. A login screen is often the first real conversation your app has with the user. That means tone, layout, spacing, button states, and error feedback matter more than people sometimes admit.
When the user taps “Sign In,” show that something is happening. Disable the button briefly, display a progress indicator, and avoid letting the user tap multiple times. If an error occurs, put the message close to the field that caused the problem, not hidden in a toast that disappears too quickly. If verification is needed, explain why in plain language. If the password reset email was sent, tell the user where to look and what to do next.
Small touches matter too. For example, auto-trimming input avoids invisible mistakes. Hiding and revealing passwords helps with accuracy. Showing the user’s email after login helps reassure them that the correct account is active. These details make authentication feel considerate instead of mechanical.
A simple login screen example in Kotlin
Here is a more complete example that combines validation, sign-in, and friendly messages:
class LoginActivity : AppCompatActivity() {
private lateinit var auth: FirebaseAuth
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_login)
auth = FirebaseAuth.getInstance()
val emailInput = findViewById<android.widget.EditText>(R.id.emailInput)
val passwordInput = findViewById<android.widget.EditText>(R.id.passwordInput)
val loginButton = findViewById<android.widget.Button>(R.id.loginButton)
loginButton.setOnClickListener {
val email = emailInput.text.toString().trim()
val password = passwordInput.text.toString().trim()
if (email.isEmpty()) {
emailInput.error = "Email is required"
return@setOnClickListener
}
if (password.isEmpty()) {
passwordInput.error = "Password is required"
return@setOnClickListener
}
loginButton.isEnabled = false
auth.signInWithEmailAndPassword(email, password)
.addOnCompleteListener(this) { task ->
loginButton.isEnabled = true
if (task.isSuccessful) {
Toast.makeText(this, "Login successful", Toast.LENGTH_SHORT).show()
// Navigate to home
} else {
val error = when (task.exception) {
is com.google.firebase.auth.FirebaseAuthInvalidUserException ->
"No account found with this email."
is com.google.firebase.auth.FirebaseAuthInvalidCredentialsException ->
"Wrong email or password."
else ->
task.exception?.localizedMessage ?: "Login failed"
}
Toast.makeText(this, error, Toast.LENGTH_LONG).show()
}
}
}
}
}
This example is basic, but it already shows a stronger pattern than simply calling Firebase directly with no checks. It gives the user immediate feedback and prevents duplicate taps. In real usage, you would likely show a ProgressBar or loading overlay instead of only disabling the button.
Password visibility and form polish
A surprisingly useful improvement is the ability to toggle password visibility. It reduces typing mistakes and makes users feel more in control. While this is not Firebase-specific, it belongs in any serious auth flow.
You might also add:
input validation before network requests,
keyboard actions such as “Next” and “Done,”
automatic focus movement between fields,
clear error text below inputs,
and a clean empty state when the screen first loads.
These things do not sound dramatic, but they create a sense of care. Users may not be able to explain why a login screen feels good, but they can absolutely tell when it feels clumsy. A thoughtful auth screen is a signal that the app was built by someone paying attention.
Session persistence in Firebase
One of the nicest parts of Firebase Authentication is that sessions persist automatically by default on Android. That means if the user closes the app and returns later, Firebase can still remember the authenticated state unless the user signs out or the session becomes invalid.
This behavior is convenient because it saves users from repeated logins. It also reduces abandonment. Every extra login screen is a chance for someone to leave. That is why many apps route returning authenticated users directly to the main content after launch.
A common pattern is:
val user = FirebaseAuth.getInstance().currentUser
if (user != null) {
startActivity(Intent(this, HomeActivity::class.java))
finish()
} else {
startActivity(Intent(this, LoginActivity::class.java))
finish()
}
That simple check often lives in a splash screen, launcher activity, or a startup decision screen. It keeps the experience smooth and makes the app feel responsive.
Security best practices
Authentication is not only about convenience. It is also about trust. Even though Firebase handles the identity layer, you still need to think about how your app treats authenticated users and what data it exposes.
First, never store raw passwords in your app or in your own database. Firebase Authentication already handles this part securely. Second, protect your backend data with Firebase Security Rules or your own server-side authorization checks. Authentication only answers the question “Who is this?” It does not automatically answer “What are they allowed to do?”
Third, consider email verification for sensitive flows. Fourth, be careful with logs. Do not print tokens, credentials, or user private data. Fifth, make sure logout really ends the visible session in your app, not just the Firebase state. A user who signs out should not still see private screens because of a stale navigation state.
For apps that store user profiles in Firestore or Realtime Database, remember that authentication and authorization work together. A signed-in user might still not be allowed to read or write certain documents. That is not a limitation. It is the protection that keeps your app safe.
Storing user profile data separately
Firebase Authentication stores account identity information, but many apps also need profile data such as display name, avatar, role, preferences, or onboarding status. A good design is to keep auth data and app profile data separate.
For example, after creating an account, you might create a profile document in Firestore:
import com.google.firebase.firestore.FirebaseFirestore
fun createUserProfile(userId: String, email: String, displayName: String) {
val db = FirebaseFirestore.getInstance()
val profile = hashMapOf(
"userId" to userId,
"email" to email,
"displayName" to displayName,
"createdAt" to System.currentTimeMillis()
)
db.collection("users").document(userId)
.set(profile)
.addOnSuccessListener {
// Profile saved
}
.addOnFailureListener { e ->
// Handle profile save failure
}
}
This separation is useful because authentication changes less often than profile data. It also gives you more flexibility later. Maybe one day you want a profile screen with settings, favorites, or subscription status. Having a dedicated user document makes that much easier.
Dealing with onboarding after authentication
A lot of apps are not really “login apps.” They are onboarding apps with login attached. After authentication, you may need to ask the user to complete a profile, accept terms, choose interests, or grant permissions. Firebase Authentication can handle the identity part, but the onboarding journey is still your responsibility.
A clean way to manage this is to store an onboarding flag in your user document. After login, check whether onboarding is complete and route accordingly. This avoids making users repeat steps and keeps the experience personal. In practical terms, it means your app can say, “Welcome back, we already know where you left off.”
Logging out on shared devices
Mobile apps are often used on personal devices, but not always. Some users log in on borrowed phones, family tablets, or shared devices. A clear sign-out option is essential in those cases. It is also a sign of respect. People need to know they can leave an account safely and completely.
After sign-out, clear any cached private UI state, navigate out of protected screens, and make sure the next person cannot casually access the previous user’s data. Firebase Auth makes the session part easy, but your own app state should also be cleaned up. That means forms, temporary data, and any in-memory sensitive information should be reset too.
Testing Firebase Authentication flows
Testing authentication can be tricky because it involves remote services and user state. Still, it is worth testing systematically. At minimum, test the following paths in your app: successful registration, duplicate email registration, successful login, wrong password, password reset, sign out, session persistence after app restart, and email verification flow.
In unit tests, you might abstract Firebase behind an interface and test your repository logic with fakes or mocks. In integration testing, you can test UI behavior and basic flow transitions. The more central authentication is to your app, the more careful you should be.
A great authentication flow should behave predictably in success and failure. Users should never feel trapped, and developers should never feel unsure about what happens next.
Common mistakes to avoid
A few mistakes appear again and again in Firebase Authentication projects. One of the biggest is putting all auth logic directly inside activities or composables. That often works in the beginning, but it becomes painful when the app grows. Another mistake is ignoring error messages and showing only a generic “Something went wrong” response. Generic messages may be safe, but they are not helpful.
Another common mistake is allowing users to hit the sign-in button repeatedly without disabling it during the request. This can cause duplicated operations or confusing UI behavior. Similarly, forgetting to check email verification can lead to partially trusted accounts moving through the app too early.
It is also easy to forget that authentication is not authorization. Just because a user is logged in does not mean they should be allowed to do everything. Security rules and backend validation still matter. Finally, many apps forget to handle the logout path with the same care as login. A polished app should treat sign-out as an important state transition, not a side note.
Firebase Authentication with Jetpack Compose
If you are using Jetpack Compose, the same authentication principles still apply. The difference is mainly in how you present and manage UI state. Compose works beautifully with ViewModels and state flows, which makes it a strong choice for auth screens.
A simple Compose login screen might look like this:
@Composable
fun LoginScreen(
email: String,
password: String,
onEmailChange: (String) -> Unit,
onPasswordChange: (String) -> Unit,
onLoginClick: () -> Unit,
isLoading: Boolean,
errorMessage: String?
) {
Column(modifier = Modifier.padding(16.dp)) {
Text(text = "Welcome back")
Spacer(modifier = Modifier.height(16.dp))
TextField(
value = email,
onValueChange = onEmailChange,
label = { Text("Email") },
modifier = Modifier.fillMaxWidth()
)
Spacer(modifier = Modifier.height(8.dp))
TextField(
value = password,
onValueChange = onPasswordChange,
label = { Text("Password") },
modifier = Modifier.fillMaxWidth()
)
Spacer(modifier = Modifier.height(16.dp))
Button(
onClick = onLoginClick,
modifier = Modifier.fillMaxWidth(),
enabled = !isLoading
) {
Text(if (isLoading) "Signing in..." else "Login")
}
errorMessage?.let {
Spacer(modifier = Modifier.height(12.dp))
Text(text = it)
}
}
}
Behind this UI, your ViewModel can call Firebase through a repository. This keeps Compose screens clean and testable. It also makes it easy to show loading states and error messages without cluttering the UI code with network logic.
Firebase Authentication and real-world app architecture
In real projects, authentication should be designed as part of the app architecture, not as a small isolated feature. The login screen is usually the front door, but after that comes profile state, permissions, navigation, and data access. If the authentication layer is weak or messy, everything downstream becomes harder to maintain.
A common and effective structure is:
UI layer for displaying fields, buttons, and state,
ViewModel for handling user actions and emitting UI state,
Repository for Firebase calls,
Optional domain layer if the app is larger and more complex.
This structure gives you room to grow. Today you may only need email/password and Google sign-in. Tomorrow you may add anonymous guest access, account linking, or passwordless flows. A clean architecture helps you adapt without a rewrite.
Final thoughts
Firebase Authentication in Kotlin Android apps is one of those tools that can genuinely save time without sacrificing quality. It helps you move quickly, but it also supports strong security, flexible sign-in methods, and a polished user experience when used thoughtfully. The real win is not only that Firebase handles the hard parts. The real win is that it frees you to focus on the parts users actually remember: clarity, speed, trust, and ease.
A login screen is often the first meaningful handshake between your app and the person using it. That is a small moment, but important things often are. When authentication feels smooth, people do not think about it much. They simply move forward. And that is exactly how it should feel.
If you build Firebase Authentication carefully in Kotlin, with clean architecture, thoughtful validation, helpful error messages, and a little human warmth in the interface, you end up with more than a working login system. You end up with a front door that feels safe, welcoming, and ready for real users.