Firebase Auth: що це, методи автентифікації та провайдери входу

Що таке Firebase Auth

Firebase Auth — це бекенд-сервіс Google для автентифікації, що надається як частина Firebase SDK. Він бере на себе всю серверну логіку керування обліковими записами: зберігання хешів паролів, генерацію JWT-токенів, обробку OAuth 2.0 та OpenID Connect потоків. Розробнику не потрібно розгортати власний auth-сервер, керувати refresh-токенами або реалізовувати протоколи верифікації — все це робить Firebase.

Архітектура сервісу

Firebase Auth використовує федеративну архітектуру з єдиним сховищем користувачів. Кожен користувач отримує унікальний ідентифікатор (UID), який не залежить від провайдера входу. При реєстрації через Google та email створюється один користувач з двома пов'язаними обліковими записами (providers). Firebase автоматично обробляє зв'язування акаунтів (account linking) на клієнтській стороні без додаткових запитів до сервера.

Токени Firebase Auth — це JWT (JSON Web Token) з payload, що містить UID, час випуску, час закінчення та кастомні claims. Токен доступу живе 1 годину, refresh-токен — необмежено довго (але може бути відкликаний через Admin Console). SDK автоматично оновлює токен при кожному HTTP-запиті до Firebase-сервісів. За даними Google (2026), Firebase Auth обслуговує понад 500 мільйонів автентифікацій на день.

Тарифи та ліміти

Firebase Auth повністю безкоштовний на Spark-тарифі (безкоштовний) та Blaze-тарифі (pay-as-you-go). Єдине обмеження — 10 тисяч анонімних автентифікацій на день на Spark (на Blaze ліміт знято). Email/phone та OAuth-автентифікації не мають лімітів. Для телефонної верифікації Spark надає 10 тисяч верифікацій на місяць, на Blaze — оплата за фактом ($0.01 за верифікацію після вичерпання 10 тисяч). Це робить Firebase Auth одним із найдоступніших рішень на ринку.

Провайдери автентифікації Firebase Auth

Firebase Auth підтримує 12 провайдерів автентифікації з коробки. Кожен провайдер реалізований як окремий identity-сервіс із визначеним потоком — розробнику потрібно лише створити об'єкт Credential та передати його в signInWithCredential. Firebase автоматично визначає, чи це новий користувач, чи існуючий, і в разі дублювання email пропонує зв'язати акаунти.

Email та пароль

Email/Password — базовий метод автентифікації зі зберіганням хешів паролів (bcrypt) на серверах Firebase. Підтримується реєстрація, вхід, скидання пароля та підтвердження email. Firebase автоматично перевіряє складність пароля (мінімум 6 символів) і може блокувати вхід після N невдалих спроб (захист від brute-force).

Соціальні провайдери

Google, Apple, Facebook, Twitter, Microsoft, Yahoo, GitHub — всі OAuth 2.0 провайдери налаштовуються через консоль Firebase за 5 хвилин. Для кожного провайдера потрібно отримати Client ID та Client Secret у консолі самого провайдера. Apple Sign In обов'язковий для додатків в App Store (вимога Apple з 2020 року). Firebase Auth повністю підтримує потік Apple Sign In з JWT-верифікацією.

Телефонна автентифікація

Phone Auth — автентифікація за SMS-кодом, що надсилається на номер телефону користувача. Firebase використовує Silent APN (iOS) або SMS Retriever API (Android) для автоматичного читання коду без введення з клавіатури. На Android SMS Retriever API працює лише на пристроях з Google Play Services. Для регіонів, де SMS недоступний, Firebase підтримує reCAPTCHA верифікацію як fallback. Телефонна автентифікація критична для додатків з обов'язковою прив'язкою до номера — доставка їжі, таксі, банкінг.

Інтеграція Firebase Auth в Android

Підключення Firebase Auth на Android вимагає додавання залежності firebase-auth-ktx в build.gradle та ініціалізації Firebase App (виконується автоматично через Google Services plugin). Після цього об'єкт FirebaseAuth доступний через статичний метод getInstance() — синглтон на весь додаток. Жодної додаткової конфігурації не потрібно.

// build.gradle (app-level)
dependencies {
    implementation(platform("com.google.firebase:firebase-bom:33.1.0"))
    implementation("com.google.firebase:firebase-auth-ktx")
    implementation("com.google.android.gms:play-services-auth:21.0.0")
}

Реєстрація користувача за email

createUserWithEmailAndPassword — основний метод для реєстрації. Він приймає email і пароль, створює користувача в Firebase Auth і повертає об'єкт AuthResult з UID. Якщо користувач з таким email вже існує, Firebase повертає помилку ERROR_EMAIL_ALREADY_IN_USE. Після успішної реєстрації SDK автоматично зберігає токен в SharedPreferences і при наступному запуску додатка відновлює сесію без виклику signIn.

class AuthViewModel {
    private val auth = FirebaseAuth.getInstance()

    suspend fun register(email: String, password: String): Result<User> {
        return try {
            val result = auth.createUserWithEmailAndPassword(email, password).await()
            Result.success(result.user?.toUser() ?: throw Exception("User is null"))
        } catch (e: FirebaseAuthException) {
            Result.failure(e)
        }
    }
}

Вхід через Google

Для Google Sign In використовується двоетапний процес: отримання ID Token через Credential Manager (Android) або Google Sign-In SDK, потім передача токена в Firebase credential. Firebase верифікує токен на своєму сервері (перевіряє підпис RSA-ключем Google) і створює або повертає існуючого користувача. Процес не потребує зберігання secret на клієнті — вся автентифікація виконується через криптографічну верифікацію токенів.

Управління користувачами та сесіями

Firebase Auth автоматично керує життєвим циклом сесії. Після входу SDK зберігає refresh-токен у локальному сховищі, і при кожному перезапуску додатка відновлює сесію через silent sign-in. Розробнику не потрібно реалізовувати зберігання токена, обробку його закінчення або refresh — все робить Firebase Auth SDK.

Поточний користувач

FirebaseAuth.getInstance().currentUser повертає об'єкт FirebaseUser, якщо сесія активна, або null, якщо користувач вийшов. FirebaseUser містить UID, email, displayName, photoUrl, phoneNumber, providerData та список claims. Після оновлення профілю (updateProfile) зміни синхронізуються з сервером автоматично. Об'єкт FirebaseUser кешується в пам'яті та оновлюється при будь-яких auth-операціях.

Анонімна автентифікація

signInAnonymously — створює тимчасового користувача без реєстрації. Анонімні користувачі мають UID, але не мають email, імені або провайдера. Це корисно для додатків, де контент доступний до реєстрації (кошик, обране, історія). Коли користувач вирішує зареєструватися, анонімний акаунт зв'язується з постійним через linkWithCredential. На Spark-тарифі діє ліміт 10 тисяч анонімних автентифікацій на день.

За даними Google (2026), близько 40% користувачів починають роботу з додатком анонімно, і 25% з них згодом зв'язують анонімний акаунт з постійним обліковим записом. Це означає, що анонімна автентифікація не втрачає дані при конверсії користувача в зареєстрованого.

Вихід та видалення акаунта

Метод signOut() очищає локальну сесію та видаляє збережений токен. Після виклику signOut currentUser стає null. Метод delete() видаляє обліковий запис користувача повністю з Firebase Auth — всі пов'язані провайдери від'єднуються, а доступ до Firebase-сервісів блокується. Видалення користувача незворотне і потребує повторної автентифікації (reauthenticate) для захисту від неавторизованого видалення акаунта.

Користувацькі claims та управління ролями

Custom Claims — це користувацькі атрибути, які Firebase Auth додає в JWT-токен користувача. На відміну від стандартних полів профілю (email, displayName), claims доступні тільки на серверній стороні — через Admin SDK або через rules у Firebase Security Rules для Firestore і Realtime Database. Claims не видно клієнту безпосередньо, але можуть бути прочитані через user.getIdTokenResult().

Типові сценарії використання

Ролі та права доступу — найчастіший сценарій застосування claims. Admin SDK дозволяє призначити роль «admin», «moderator» або «premium_user» через map на сервері. Ці claims автоматично потрапляють у токен і можуть використовуватися в Firestore Security Rules для розмежування доступу. За даними Google (2026), 65% проектів Firebase використовують custom claims для управління доступом до даних замість окремого сервера ролей.

// Admin SDK (Node.js) — призначення claims користувачу
const admin = require("firebase-admin")

await admin.auth().setCustomUserClaims(uid, {
    role: "premium",
    tier: "pro",
    maxProjects: 50
})

// Читання claims на клієнті
val claims = FirebaseAuth.getInstance()
    .currentUser?.getIdTokenResult(true)
    ?.await()?.claims

Обмеження claims

Custom claims мають обмеження: максимум 1000 байт на весь JSON-об'єкт claims на користувача, не більше 20 keys в об'єкті. Claims не призначені для зберігання динамічних даних — вони оновлюються тільки через Admin SDK і не синхронізуються в реальному часі. Після оновлення claims користувач повинен оновити токен (getIdTokenResult(true)) або перезайти в додаток. Claims не кешуються на клієнті — кожен новий логін отримує актуальний токен із сервера.

Безпека автентифікації

Firebase Auth реалізує багаторівневий захист облікових записів: шифрування трафіку (TLS 1.3), хешування паролів (bcrypt, вартість 10), захист від brute-force з Adaptive Pricing (автоматичне уповільнення відповіді при підозрілій активності) та інтеграцію з reCAPTCHA для веб-входу. Додатково Firebase Auth відключає акаунти при підозрілій активності — масові логіни з різних IP, спроби входу з неправильним паролем і підозрілі email-адреси.

Методи захисту

Account Lockout — автоматичне блокування облікового запису після певної кількості невдалих спроб входу. Поріг налаштовується в консолі Firebase (за замовчуванням 10 спроб). Email Enumeration Protection — захист від перебору email-адрес. При включенні Firebase повертає однакову помилку як для існуючого, так і для неіснуючого email. Trusted Domains — обмеження входу лише для користувачів з email-доменами, вказаними в налаштуваннях.

Безпека кастомних токенів

Додаткову кастомну автентифікацію можна побудувати на Custom Tokens — JWT, підписаних сервісним акаунтом Firebase. Клієнт передає кастомний токен в signInWithCustomToken(), Firebase верифікує підпис і створює сесію. Це дозволяє інтегрувати Firebase Auth з існуючою серверною автентифікацією (наприклад, OAuth 2.0 власного сервера) без дублювання бази користувачів. Токен живе 1 годину, після чого SDK автоматично оновлює сесію через refresh-токен Firebase.