Theory
When login goes wrong
Authentication does not always succeed. A user mistypes their password, tries to register an email that already exists, or picks a password that is too weak. If your app ignores these failures, the user sees nothing happen, or worse, a crash. A good app catches each failure and tells the user clearly what to fix.
Firebase reports auth failures through the Task you already handle: when it fails, task.exception says why. This lesson covers the common auth errors and how to turn them into friendly messages. Handling errors well is what separates a polished app from a frustrating one.
At a glance
| Exception | Typical cause |
|---|---|
| FirebaseAuthInvalidUserException | No account for that email (or it is disabled/deleted) |
| FirebaseAuthInvalidCredentialsException | Wrong password, or a malformed email address |
| FirebaseAuthUserCollisionException | Registering an email that is already in use |
| FirebaseAuthWeakPasswordException | The chosen password is too weak (on registration) |
Practical
Turning a failed Task into a friendly message
auth.signInWithEmailAndPassword(email, password)
.addOnCompleteListener { task ->
if (task.isSuccessful) {
// proceed to the app
} else {
val message = when (task.exception) {
is FirebaseAuthInvalidUserException ->
"No account found for that email."
is FirebaseAuthInvalidCredentialsException ->
"Incorrect email or password."
else -> "Sign-in failed. Please try again."
}
showError(message) // display it on your UI, do not crash
}
}Formula
Catch the failure, guide the user
The rule: never let an auth failure be silent or raw. Always check task.isSuccessful, and when it is false, read task.exception to decide what to say.
Map each error to a clear, friendly message the user can act on: 'Incorrect email or password', 'That email is already registered, try logging in', 'Please choose a stronger password'. Do not show the raw exception or stack trace, it confuses users and can leak details. And be careful not to reveal too much (for security, a vague 'incorrect email or password' is often better than 'no such user', which tells an attacker which emails exist). Helpful, safe messages guide the user to success.
Quiz
A user tries to register with an email that already has an account. Which Firebase exception signals this, and how should the app respond?
- FirebaseAuthWeakPasswordException; ask for a longer password
- FirebaseAuthUserCollisionException; show a friendly message like 'That email is already registered, try logging in'
- It should crash so the developer notices
- No exception occurs; the duplicate is silently ignored
Show the answer
FirebaseAuthUserCollisionException; show a friendly message like 'That email is already registered, try logging in'
Registering an email that is already in use raises FirebaseAuthUserCollisionException, and the app should catch it from task.exception and show a clear, friendly message such as 'That email is already registered, try logging in'. Option A names the wrong exception: FirebaseAuthWeakPasswordException is for a password that is too weak, not a duplicate email. Option C is bad practice: a failed registration is an expected situation to handle gracefully, not a reason to crash. Option D is wrong: Firebase does not silently ignore it; it reports the collision so you can inform the user. Match the exception to the cause and turn it into helpful guidance.
Think first
Why can revealing too much in an auth error be a security risk?
A precise message like 'no account exists for that email' seems helpful. Why might a vaguer 'incorrect email or password' be safer? Then tap.
Show the answer
Because overly precise auth errors can leak information that helps attackers, most notably whether a given email is REGISTERED on your app, a technique called account enumeration. Suppose your login error distinguishes 'no account for that email' from 'wrong password'. An attacker can now probe your app with a list of email addresses: the ones that return 'wrong password' clearly HAVE accounts, while 'no account' ones do not. This hands them a confirmed list of your users' emails, which they can target with phishing, credential-stuffing (trying passwords leaked from other breaches), or social engineering, and it may even reveal that a specific person uses your service, a privacy concern in itself. Using a single, vaguer message for login failures, like 'incorrect email or password', denies the attacker that signal: they cannot tell whether the email exists or the password was wrong, so probing yields nothing useful. There is a genuine trade-off with usability (a precise message is friendlier to honest users who simply forgot which email they used), so many apps balance it, being vaguer on login while still giving clear, specific guidance where it is safe (for example, on registration you may say an email is already in use, and for password strength you should say the password is too weak). The principle is to reveal enough to help legitimate users without handing attackers a map of your accounts. Helpful to users, unhelpful to attackers, is the balance to aim for.
Summary
Key takeaways
- Authentication fails in predictable ways; good apps catch each failure and show a clear message.
- On a failed Task, task.exception holds the reason; check task.isSuccessful first.
- Common exceptions: FirebaseAuthInvalidUserException (no such user), FirebaseAuthInvalidCredentialsException (wrong password/bad email), FirebaseAuthUserCollisionException (email already in use), FirebaseAuthWeakPasswordException (weak password).
- Map each to a friendly, actionable message; never show raw exceptions or leave failures silent.
- On registration, a collision means 'that email is already registered'; a weak password means 'choose a stronger one'.
- Avoid revealing too much (like whether an email exists) to prevent account enumeration; a vague login error is often safer.
- Memory hook: check the Task, read the exception type, show a helpful and safe message.