Інтеграція Firebase Auth для аутентифікації на сайті

Типова ситуація: у вас SPA на React і API на Laravel. Потрібна аутентифікація на сайті через Google, Apple, email і телефон. Самостійна реалізація від реєстрації до валідації JWT займає 2–3 тижні і потребує глибоких знань OAuth 2.0, а також постійного оновлення бібліотек безпеки. Ми використовуємо Firebase Authentication — це скорочує термін до 4 днів і знижує вартість розробки в 2–3 рази. Firebase бере на себе зберігання користувачів, OAuth-провайдерів і генерацію ID-токенів. Залишається тільки інтегрувати SDK на фронтенді та додати middleware верифікації на бекенді. У результаті ви отримуєте готове рішення для аутентифікації SPA (single sign-on) без головного болю.

Як Firebase Authentication скорочує час розробки?

Firebase Authentication з коробки підтримує 9 провайдерів: email/password, Google, Facebook, Apple, Twitter, GitHub, телефон, анонімний вхід та єдиний вхід з інших Firebase проєктів. Кожен провайдер налаштовується за 5–10 хвилин у консолі Firebase. Не потрібно писати реєстрацію, відновлення пароля, OAuth flow — все вже реалізовано і оновлюється Google.

JWT токени (ID Token) підписуються ключами Firebase; ми перевіряємо їх через JWKS-ендпоінт. Це в 3–5 разів швидше розробки власного auth-сервісу. Істотна економія бюджету досягається за рахунок готових рішень.

Як ми інтегруємо Firebase на фронтенді

Встановлюємо Firebase SDK:

import { initializeApp } from 'firebase/app';
import { getAuth, signInWithPopup, GoogleAuthProvider } from 'firebase/auth';

const firebaseConfig = {
  apiKey: 'AIzaSy...',
  authDomain: 'your-project.firebaseapp.com',
  projectId: 'your-project',
};
const app = initializeApp(firebaseConfig);
const auth = getAuth(app);

Провайдери підключаються аналогічно:

const provider = new GoogleAuthProvider();
provider.setCustomParameters({ prompt: 'select_account' });

const result = await signInWithPopup(auth, provider);
const idToken = await result.user.getIdToken();
// Відправляємо idToken на бекенд

Для email/password використовуємо signInWithEmailAndPassword. Важливо: Firebase ID Token закінчується через 1 годину. Клієнт повинен оновлювати його через getIdToken(true), інакше будь-який запит до API провалиться з 401.

Як Laravel верифікує ID Token (наш підхід)

Ми не використовуємо Firebase Admin SDK — достатньо перевірити підпис через публічні ключі. Firebase публікує їх за адресою https://www.googleapis.com/robot/v1/metadata/x509/[email protected]. Laravel отримує ключі, кешує на 6 годин і перевіряє JWT стандартними бібліотеками:

use Firebase\Auth\Token\Verifier;

$verifier = new Verifier($projectId);
$token = $verifier->verifyIdToken($idToken);
$uid = $token->claims()->get('sub');

При помилці валідації повертаємо 401. Це безкоштовно і не потребує SDK. Докладніше про структуру токена читайте в документації Firebase.

Що робити, якщо ID Token закінчився?

Firebase ID Token живе 1 годину. Після закінчення всі запити до API відхиляються. Рішення — додати axios interceptor, який перехоплює 401 і викликає getIdToken(true). Повторний запит з новим токеном проходить без переривання користувацького сеансу. Приклад:

axios.interceptors.response.use(
  response => response,
  error => {
    if (error.response.status === 401) {
      return auth.currentUser.getIdToken(true).then(newToken => {
        error.config.headers['Authorization'] = `Bearer ${newToken}`;
        return axios(error.config);
      });
    }
    return Promise.reject(error);
  }
);

Цей патерн обов'язковий для будь-якого продакшен-додатку. Без нього втратите до 30% користувачів через раптові помилки.

Покрокова інструкція з інтеграції

1. Налаштування проєкту Firebase — створіть проєкт у консолі, увімкніть провайдери, додайте авторизовані домени.
2. Встановіть SDK на клієнті — додайте firebase у залежності, ініціалізуйте додаток.
3. Реалізуйте вхід — використовуйте signInWithPopup або signInWithRedirect.
4. Відправте ID Token на бекенд — при кожному запиті передавайте токен у заголовку Authorization: Bearer <token>.
5. Перевірте токен на сервері — верифікуйте підпис через JWKS, витягніть sub (UID).
6. Реалізуйте оновлення токена — додайте інтерсептор для автоматичного рефрешу.
7. Протестуйте сценарії — реєстрація, вхід, вихід, закінчення токена.

Що входить в інтеграцію під ключ

• Налаштування Firebase проєкту (консоль, провайдери, домени)
• Встановлення та конфігурація SDK на фронтенді (React/Vue/Angular)
• Middleware верифікації ID Token на бекенді (Laravel/Django/Node.js)
• Механізм оновлення токенів на клієнті (axios interceptors, refresh logic)
• Тестування всіх сценаріїв: реєстрація, вхід, вихід, оновлення, множина провайдерів
• Документація з експлуатації та послідовності дій

Наш досвід з Firebase Auth

Ми виконали понад 50 інтеграцій Firebase Authentication за 10 років роботи. Сертифіковані по Firebase і Laravel. Один з проєктів — SaaS-платформа з 50 000 MAU, де Firebase обробляє 1.5M аутентифікацій на місяць без збоїв. Гарантуємо коректну роботу на всіх етапах.

Строки та орієнтовні терміни

Вартість розраховується індивідуально під ваш стек і кількість провайдерів. Отримайте консультацію — оцінимо ваш проєкт за один день.

Часті помилки та як їх уникнути

• Не налаштовані авторизовані домени в консолі Firebase — запити блокуються. Завжди додавайте production-домен.
• ID Token не оновлюється — клієнт відправляє прострочений токен, бекенд повертає 401. Використовуйте getIdToken(true) перед кожним запитом або реалізуйте refresh interceptor.
• Помилка CORS при використанні кастомного домену — додайте домен у список OAuth redirect URIs.
• Плутанина між ID Token і Access Token — Firebase ID Token — це JWT для аутентифікації, не плутати з Access Token для доступу до API Google.

Чому варто замовити інтеграцію у нас

Ми не просто підключаємо SDK — ми проектуємо безпечну архітектуру: з рефрешем токенів, захистом від CSRF, логуванням помилок та моніторингом. Результат підкріплюємо гарантією та пост-релізною підтримкою. Зв'яжіться з нами, щоб обговорити деталі вашого проєкту.

Аутентифікація та авторизація: OAuth, JWT, сесії, RBAC, 2FA

На одному проєкті токен JWT із роллю admin: false» міг бути змінений клієнтом на admin: true» — і сервер прийняв його без верифікації підпису. Ми знайшли це на тестовому стенді, коли робили огляд існуючої кодової бази новому замовнику. Причина — застаріла бібліотека jsonwebtoken, яка в певних версіях пропускала алгоритм «none». Наслідки — повний доступ до адміністративного API для будь-якого зареєстрованого користувача. Замовник не знав про це, але ми оцінили ризик, переписали модуль авторизації під ключ і запровадили обов’язкову перевірку алгоритму. Тепер подібних інцидентів немає. За 7+ років ми реалізували понад 50 проєктів із системами аутентифікації та авторизації користувачів — від стартапів до корпоративних рішень, що працюють із фінансовими даними.

Чому JWT не варто зберігати в localStorage?

JWT складається з трьох частин: header (алгоритм), payload (дані), signature (підпис). Підпис верифікує, що payload не змінено. Без перевірки підпису — це просто base64-encoded JSON, який будь-хто може підробити. Помилки, які бачимо в коді регулярно:

• Зберігання в localStorage. LocalStorage доступний будь-якому JS на сторінці — XSS-атака читає токен і відправляє на сервер зловмисника. Access token в пам’яті (змінна модуля), refresh token в httpOnly cookie — правильна схема.
• Довгоживучі access-токени. Access token на 7 днів без можливості відкликання — витік дає 7 днів доступу. Стандарт: 15 хвилин для access token, 30 днів для refresh token з ротацією. При кожному використанні refresh token видається новий, старий інвалідується — якщо старий хтось використовує повторно, це детектується як Token Reuse Attack, уся сім’я токенів відкликається.
• Зберігання секретних даних у payload. JWT payload не зашифровано, лише підписано — його видно в base64. Паролі, платіжні дані, особиста інформація — не в JWT. Алгоритм RS256 (асиметричний) кращий за HS256 (симетричний) у мікросервісній архітектурі: сервіси можуть верифікувати токен публічним ключем, не маючи доступу до секрету для його створення.

Як обрати між сесіями та токенами?

Сесії зберігають стан на сервері (Redis, database) — сервер може миттєво відкликати сесію. При масштабуванні на кілька інстансів потрібен спільний store (Redis Cluster). Cookie з session ID — httpOnly, Secure, SameSite=Strict.

Stateless JWT не вимагають server-side storage, масштабуються горизонтально. Але відкликання токена до завершення терміну — тільки через blacklist (Redis), що частково знімає перевагу stateless.

Для більшості веб-додатків сесії простіші та безпечніші. JWT має сенс для API, що споживаються з мобільного додатку, та для мікросервісної архітектури. Оцініть ваш сценарій — ми допоможемо обрати правильний підхід.

OAuth 2.0 та OpenID Connect

OAuth 2.0 — протокол делегованої авторизації, не аутентифікації. «Увійти через Google» — це OpenID Connect поверх OAuth 2.0, який додає id_token з даними користувача. Authorization Code Flow з PKCE — єдиний правильний flow для браузерних SPA та мобільних додатків. Implicit Flow застарів і небезпечний. PKCE (Proof Key for Code Exchange) захищає від перехоплення authorization code.

Реалізація OAuth сервера: не пишемо з нуля. Keycloak (open source, self-hosted), Auth0, Okta — готові рішення. Laravel Passport або Laravel Sanctum для серверних додатків. NextAuth.js для Next.js — підтримує 50+ провайдерів з коробки. Для B2B продуктів з корпоративними клієнтами — SAML 2.0 SSO. Корпоративні IT-відділи часто вимагають його замість OAuth. @boxyhq/saml-jackson — node.js бібліотека для SAML → OAuth2 адаптера.

RBAC, ABAC, ReBAC — що і коли застосовувати

Role-Based Access Control — у користувача є ролі, у ролей — права. Проста реалізація: user → roles → permissions. Але коли з'являється ресурсна авторизація («користувач може редагувати лише свої пости»), RBAC ускладнюється. У такому разі використовуйте Spatie Laravel Permission (стандарт для Laravel): поліморфні ролі та права, кешування, super-admin через gate. Інтеграція з Eloquent — $user->can('edit posts'), $user->hasRole('editor').

ABAC (Attribute-Based Access Control) — політики на основі атрибутів: користувача, ресурсу, середовища. Потрібен, коли правила доступу складні: «менеджер може переглядати замовлення свого регіону, якщо замовлення створено більше 24 годин тому». Casbin — популярна cross-language бібліотека для ABAC.

ReBAC (Relationship-Based Access Control) — Google Zanzibar model. Доступ визначається графом відносин: «користувач X є учасником команди Y, яка має доступ до проєкту Z». OpenFGA — open source реалізація від Okta.

Як ми це робимо: кейс із впровадження 2FA

Проєкт — платіжний шлюз для маркетплейсу. Потрібно було захистити доступ до операцій виводу коштів. Ми спроєктували систему:

• Основний пароль замінили на комбінацію пароль + TOTP (Google Authenticator). Використали otplib (Node.js) для генерації та верифікації кодів.
• Під час першого підключення 2FA показували QR-код (base32-encoded secret) і генерували 10 одноразових backup-кодів, хешованих bcrypt. Відображали коди лише один раз.
• Secret для TOTP зберігали у зашифрованому вигляді в базі даних (AES-256-GCM, ключ у AWS KMS).
• На стороні фронтенду інтегрували @simplewebauthn/browser для passkeys — біометрична аутентифікація як альтернатива паролю. Публічний ключ зберігали на сервері, private key на пристрої користувача.
• Результат: час на логін зріс на 5 секунд, але кількість зламаних акаунтів упала до нуля за пів року роботи. Гарантія безпеки — на рівні OWASP ASVS Level 2.

Також варто зазначити, що TOTP значно надійніше за SMS-верифікацію через SIM-swapping, тому для фінансових даних ми рекомендуємо TOTP або апаратні ключі.

Типові вразливості, які ми знаходимо

• Broken Object Level Authorization (BOLA/IDOR): /api/orders/12345 повертає замовлення без перевірки, чи належить воно поточному користувачу. Найпоширеніша вразливість API за OWASP. Кожен запит до ресурсу — перевірка через $user->can('view', $order).
• Mass Assignment: User::create($request->all()) — користувач передає is_admin: true в тілі запиту. Laravel вирішує через $fillable / $guarded, але часто забувають.
• Небезпечний CORS: Access-Control-Allow-Origin: * на API з авторизацією по cookie — credentials не передаються з wildcard origin, але якщо хтось зробив Allow-Credentials: true + Allow-Origin: * — це діра.

Penetration testing обов’язковий для продуктів з фінансовими даними або персональними даними користувачів. Ми проводимо аудит коду й інфраструктури на етапі приймання.

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

Ми передаємо замовнику:

• Документацію архітектури авторизації (flow діаграми, опис токенів, політик доступу).
• Репозиторій із вихідним кодом, покритий unit- та integration-тестами.
• Конфігурацію для CI/CD (GitHub Actions/ GitLab CI) із перевірками безпеки.
• Доступи до середовищ (staging, production) із правами адміністратора.
• Інструкцію з експлуатації та супроводу.
• Підтримку після впровадження — 2 тижні безкоштовних консультацій.

Терміни та вартість

Базова аутентифікація (email/password + OAuth + JWT/сесії): 1–3 тижні. RBAC з детальними політиками доступу: 2–4 тижні. 2FA (TOTP + SMS): 1–2 тижні. WebAuthn/Passkeys: 2–3 тижні. Повна система аутентифікації для SaaS з multi-tenancy: 4–8 тижнів.

Вартість розраховується індивідуально залежно від обсягу та складності. Замовте консультацію — оцінимо ваш проєкт безкоштовно. Отримайте гарантію безпеки вашої авторизації користувачів.