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

Наша компания занимается разработкой, поддержкой и обслуживанием сайтов любой сложности. От простых одностраничных сайтов до масштабных кластерных систем построенных на микро сервисах. Опыт разработчиков подтвержден сертификатами от вендоров.

Разработка и обслуживание любых видов сайтов:

Информационные сайты или веб-приложения
Сайты визитки, landing page, корпоративные сайты, онлайн каталоги, квиз, промо-сайты, блоги, новостные ресурсы, информационные порталы, форумы, агрегаторы
Сайты или веб-приложения электронной коммерции
Интернет-магазины, B2B-порталы, маркетплейсы, онлайн-обменники, кэшбэк-сайты, биржи, дропшиппинг-платформы, парсеры товаров
Веб-приложения для управления бизнес-процессами
CRM-системы, ERP-системы, корпоративные порталы, системы управления производством, парсеры информации
Сайты или веб-приложения электронных услуг
Доски объявлений, онлайн-школы, онлайн-кинотеатры, конструкторы сайтов, порталы предоставления электронных услуг, видеохостинги, тематические порталы

Это лишь некоторые из технических типов сайтов, с которыми мы работаем, и каждый из них может иметь свои специфические особенности и функциональность, а также быть адаптированным под конкретные потребности и цели клиента

Услуги, которые мы предлагаем
Показано 1 из 1Все 2062 услуг
Интеграция Firebase Auth для аутентификации на сайте
Средний
от 1 дня до 3 дней
Часто задаваемые вопросы

Наши компетенции:

Этапы разработки

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1358
  • image_web-applications_feedme_466_0.webp
    Разработка веб-приложения для компании FEEDME
    1250
  • image_websites_belfingroup_462_0.webp
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    956
  • image_ecommerce_furnoro_435_0.webp
    Разработка интернет магазина для компании FURNORO
    1188
  • image_crm_enviok_479_0.webp
    Разработка веб-приложения для компании Enviok
    929
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Разработка веб-сайта для компании ФИКСПЕР
    947

Типичная ситуация: у вас 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.

Провайдер Особенности
Email/Password Встроенная форма, сброс пароля
Google Поп-ап или редирект, профиль
Apple Требуется для iOS-приложений
Телефон Одноразовый код по SMS
Facebook, Twitter, GitHub Стандартный OAuth

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)
  • Тестирование всех сценариев: регистрация, вход, выход, обновление, множество провайдеров
  • Документация по эксплуатации и последовательности действий
Подробнее о безопасности Мы добавляем защиту от CSRF, валидацию origin запросов и логирование ошибок. ID Token содержит время истечения, поэтому даже при утечке токен живёт недолго.

Наш опыт с Firebase Auth

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

Сроки и ориентировочные сроки

Этап Время
Настройка Firebase проекта 0.5 дня
Frontend SDK + провайдеры входа 1 день
Backend верификация + middleware 1 день
Обновление токенов + interceptors 0.5 дня
Тестирование и исправление ошибок 1 день
Итого 4–5 дней

Стоимость рассчитывается индивидуально под ваш стэк и количество провайдеров. Получите консультацию — оценим ваш проект за один день.

Частые ошибки и как их избежать

  • Не настроены авторизованные домены в консоли 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 — сервер принимал его без верификации подписи. Это не гипотетическая атака: несколько файлов в npm-экосистеме имели уязвимость jwt библиотеки, которая игнорировала алгоритм none. Последствия — полный доступ к административным функциям для любого зарегистрированного пользователя.

JWT: что реально нужно знать

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 (симметричный) в микросервисной архитектуре: сервисы могут верифицировать токен публичным ключом, не имея доступа к секрету для его создания.

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 адаптера.

Сессии vs токены

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

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

Для большинства веб-приложений сессии проще и безопаснее. JWT имеет смысл для API, потребляемых из мобильного приложения, и для микросервисной архитектуры.

RBAC и политики доступа

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.

Двухфакторная аутентификация

TOTP (Time-based One-Time Password, Google Authenticator, Authy) — стандарт. Библиотеки: otplib (Node.js), pragmarx/google2fa (Laravel). QR-код при подключении — base32-encoded secret, которого достаточно для воспроизведения кода при компрометации. Хранить secret в зашифрованном виде.

SMS-верификация — слабее TOTP из-за SIM-swapping атак и ненадёжности доставки SMS. Но пользователи активируют её охотнее. Email OTP — компромисс между безопасностью и UX.

WebAuthn (Passkeys) — биометрия или аппаратный ключ вместо пароля. Хранится private key на устройстве, публичный — на сервере. Нет пароля — нет его утечки. iOS 16+, Android 9+, все современные браузеры поддерживают. @simplewebauthn/server + @simplewebauthn/browser — хорошая библиотека для Node.js реализации.

Backup-коды при подключении 2FA: 10 одноразовых кодов для восстановления доступа если телефон потерян. Хранить хешированными (bcrypt), показывать только один раз при генерации.

Типичные уязвимости

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: * — это дыра.

Процесс работы

Архитектура авторизации проектируется до начала разработки, не добавляется потом. Выбор между сессиями и JWT, структура ролей и прав, flow для OAuth-провайдеров, план для 2FA. Penetration testing обязателен для продуктов с финансовыми данными или персональными данными пользователей.

Сроки

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