Интеграция Firebase Authentication в мобильное приложение

Интеграция Firebase Authentication в мобильное приложение

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

Что чаще всего настраивают неправильно

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 день.