Інтеграція Firebase Authentication у мобільний додаток

Інтеграція Firebase Authentication у мобільний додаток

Firebase Authentication закриває великий обсяг роботи з коробки: Email/Password, Phone, Google, Apple, Facebook, GitHub, anonymous auth — усі ці провайдери готові до використання. Однак «з коробки» не означає «без конфігурації». Проєкти, які просто додали FirebaseAuth.getInstance() і вважають задачу вирішеною, регулярно отримують проблеми в продакшені. Наша команда має багаторічний досвід інтеграції Firebase Auth на iOS та Android — ми гарантуємо надійну аутентифікацію з першого разу.

Що найчастіше налаштовують неправильно

ID Token vs Custom Token vs Access Token. Firebase Auth повертає Firebase ID Token — JWT, підписаний Google. Це не OAuth 2.0 access token для стороннього API. Якщо backend не Firebase — треба верифікувати Firebase ID Token на сервері (admin.auth().verifyIdToken()), отримати UID і видати власний JWT. Бачили проєкти, де Firebase ID Token передавався напряму в сторонній API з надією, що «токен є — значить авторизовано». Це не працює. Firebase ID Token верифікація в 5 разів швидше самостійного випуску токенів.

Token refresh. Firebase SDK автоматично оновлює ID Token щогодини. Але currentUser?.getIdToken(forceRefresh: false) поверне кешований токен, який може бути за 55 хвилин до завершення. Якщо передаєте токен на backend — викликайте getIdToken(forceRefresh: true) перед кожним запитом або використовуйте Auth.auth().currentUser?.getIDTokenResult() для перевірки expirationDate.

Sign in with Apple — окрема конфігурація. Apple вимагає передачі nonce — випадкового рядка, хеш якого включається в Apple Identity Token. Firebase перевіряє цей хеш. Без nonce інтеграція працює на етапі розробки, але падає в продакшені на деяких конфігураціях Apple ID.

// iOS — правильна інтеграція Sign in with Apple + Firebase let nonce = randomNonceString() currentNonce = nonce let request = ASAuthorizationAppleIDProvider().createRequest() request.requestedScopes = [.fullName, .email] request.nonce = sha256(nonce) 

При отриманні Apple credential:

let credential = OAuthProvider.appleCredential( withIDToken: appleIDToken, rawNonce: nonce, // передаємо оригінальний nonce, не хеш fullName: appleIDCredential.fullName ) Auth.auth().signIn(with: credential) 

Phone Authentication: нюанси

Firebase Phone Auth працює через reCAPTCHA верифікацію на iOS та Play Integrity / SafetyNet на Android. Проблеми:

• На симуляторі iOS автоматично використовується invisible reCAPTCHA — у продакшені на реальному пристрої поведінка може відрізнятися (з'являється challenge).
• verifyPhoneNumber вимагає APNs налаштування для silent push на iOS — без цього верифікація не проходить на пристроях з push notifications.
• На Android: PhoneAuthProvider.verifyPhoneNumber з PhoneAuthOptions.Builder. Використовуємо setActivity(this) — без прив'язки до Activity автоматичне визначення не працює.

Тестові номери телефонів у Firebase Console (+1 650-555-3434) дозволяють тестувати без реальних SMS — додаємо їх для QA-середовища.

Listeners: AuthStateListener та IdTokenChangedListener

Два різних listener — різні події:

• addAuthStateListener спрацьовує при login/logout користувача.
• addIdTokenChangedListener спрацьовує додатково при кожному оновленні ID Token (щогодини).

Для синхронізації токена з backend — використовуємо IdTokenChangedListener. Для навігаційних рішень (показати екран логіну / приховати) — AuthStateListener.

На iOS важливо знімати listener при dealloc/deinit:

deinit { if let handle = authStateHandle { Auth.auth().removeStateDidChangeListener(handle) } } 

Інакше краш у момент, коли Firebase намагається викликати callback на вже деініціалізованому об'єкті.

Security Rules

Якщо використовуєте Firestore або Realtime Database — Security Rules мають посилатися на request.auth.uid, а не довіряти client-side логіці. Типова діра: колекція users без правила на читання — будь-який аутентифікований користувач читає дані будь-якого іншого.

Мінімальне правило:

match /users/{userId} { allow read, write: if request.auth != null && request.auth.uid == userId; } 

Як ми реалізуємо мультитенантність?

Firebase Authentication підтримує tenants (через Google Cloud Identity Platform — розширена версія Firebase Auth). Якщо у вас SaaS з ізольованими клієнтами — це правильний шлях замість створення окремих Firebase проєктів. Auth.auth().tenantID = "tenant-xyz" — перемикає контекст. Наші інженери налаштовують tenants під кожного клієнта, гарантуючи ізоляцію даних.

Що входить в роботу?

Ми також надаємо доступ до тестового середовища на час розробки та навчаємо вашу команду.

Етапи інтеграції

1. Створення Firebase проєкту та конфігурація провайдерів → 2. Додавання GoogleService-Info.plist / google-services.json → 3. Реалізація auth flow з обробкою помилок → 4. Налаштування backend-верифікації ID Token → 5. Тестування email/phone/social providers → 6. Security Rules аудит → 7. Тестування на реальних пристроях.

Термін: 6–10 робочих днів для стандартного набору провайдерів (email + google + apple). Кожен додатковий соціальний провайдер (Facebook, Twitter) — плюс 1–2 дні з урахуванням налаштування developer accounts.

Підсумок

Firebase Authentication — потужний інструмент, але вимагає уваги до деталей: налаштування провайдерів, верифікація токенів, коректна обробка стану. Зверніться до нас — ми впровадимо аутентифікацію під ключ, з документацією та підтримкою. Зв'яжіться, щоб обговорити ваш проєкт: пишіть на пошту або телефонуйте — оцінимо обсяг за 1 день.