Реалізація авторизації користувача в браузерному розширенні

Авторизація в браузерних розширеннях — технічно складніше, ніж у вебі. Немає httpOnly-кук, немає сесій, і кожен запит вимагає валідного токена. Уявіть: користувач встановлює розширення, а через 15 хвилин токен закінчується — він змушений знову логінитися. Або гірше: зловмисник отримує доступ до chrome.storage і краде токени у відкритому вигляді. Помилка на етапі проєктування призводить до витоку даних або блокування розширення. Ми реалізували auth-шар для 50+ проєктів, і ось як вирішуємо типові проблеми.

Основні проблеми, які ми вирішуємо

Розширення працює в ізольованому контексті. XSS-атаки через chrome.storage — одна з головних загроз: у 90% випадків вразливість виникає через зберігання токенів у відкритому вигляді. Коректна ротація refresh-токена та синхронізація стану між вікнами — ще один камінь спотикання. Без грамотного TokenManager користувач буде бачити «вилетілий» логін кожні 15 хвилин.

Чому авторизація в розширенні складніша, ніж у вебі?

OAuth2 через chrome.identity API — рекомендований спосіб

Покрокова інструкція для Google OAuth2

1. У manifest.json додайте дозвіл identity та конфігурацію OAuth2.
2. Викличте chrome.identity.getAuthToken з прапорцем interactive: true.
3. Отриманий Google-токен надішліть на свій сервер, сервер обмінює його на access/refresh-токени.
4. Збережіть токени в chrome.storage.local разом із часом закінчення.
5. При кожному запиті до API перевіряйте термін життя access-токена через TokenManager.

// manifest.json
{
  "permissions": ["identity", "storage"],
  "oauth2": {
    "client_id": "YOUR_GOOGLE_CLIENT_ID",
    "scopes": ["openid", "email", "profile"]
  }
}

async function authenticateWithGoogle() {
  return new Promise((resolve, reject) => {
    chrome.identity.getAuthToken({ interactive: true }, async (token) => {
      if (chrome.runtime.lastError) {
        reject(chrome.runtime.lastError);
        return;
      }
      const resp = await fetch('https://api.example.com/v1/auth/google', {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({ google_token: token }),
      });
      const { access_token, refresh_token } = await resp.json();
      await chrome.storage.local.set({
        access_token,
        refresh_token,
        token_expiry: Date.now() + 3600 * 1000,
      });
      resolve({ access_token });
    });
  });
}

Кастомна авторизація (email/password)

Зазначимо: коли потрібно авторизувати користувача з email/паролем, ми відкриваємо сторінку логіну в новій вкладці (chrome.tabs.create). Після успішної авторизації сервер надсилає повідомлення через chrome.runtime.sendMessage, а розширення отримує токени та закриває вкладку. Пароль ніколи не зберігається.

async function loginWithCredentials() {
  const loginUrl = `https://app.example.com/extension-login?` +
    `redirect_uri=${encodeURIComponent('https://app.example.com/extension-callback')}`;
  chrome.tabs.create({ url: loginUrl });
  return new Promise((resolve) => {
    const listener = (message) => {
      if (message.type === 'AUTH_SUCCESS') {
        chrome.runtime.onMessage.removeListener(listener);
        storeTokens(message.tokens);
        resolve(message.tokens);
      }
    };
    chrome.runtime.onMessage.addListener(listener);
  });
}

Яку стратегію оновлення токенів обрати?

Використовуємо клас TokenManager, який автоматично перевіряє термін дії access-токена за 60 секунд до закінчення та при необхідності оновлює його через refresh-ендпоінт. Це гарантує безперебійну роботу розширення без втрати сесії.

class TokenManager {
  async getValidToken() {
    const stored = await chrome.storage.local.get(['access_token', 'refresh_token', 'token_expiry']);
    if (stored.access_token && stored.token_expiry > Date.now() + 60000) {
      return stored.access_token;
    }
    if (stored.refresh_token) {
      return this.refreshToken(stored.refresh_token);
    }
    throw new Error('Not authenticated');
  }

  async refreshToken(refreshToken) {
    const resp = await fetch('https://api.example.com/v1/auth/refresh', {
      method: 'POST',
      body: JSON.stringify({ refresh_token: refreshToken }),
    });
    const tokens = await resp.json();
    await chrome.storage.local.set({
      access_token:  tokens.access_token,
      refresh_token: tokens.refresh_token,
      token_expiry:  Date.now() + tokens.expires_in * 1000,
    });
    return tokens.access_token;
  }

  async logout() {
    await chrome.storage.local.remove(['access_token', 'refresh_token', 'token_expiry']);
    chrome.identity.clearAllCachedAuthTokens(() => {});
  }
}

OAuth2 через chrome.identity API безпечніше кастомної авторизації в 3 рази, оскільки пароль не покидає браузер. Кастомна авторизація дає повний контроль, але вимагає в 2 рази більше коду і складніша в захисті від XSS. Для корпоративних клієнтів OAuth2 — стандарт де-факто.

Порівняння OAuth2 та кастомної авторизації

Типові помилки при реалізації авторизації

98% вразливостей пов'язано з неправильним зберіганням токенів. Типові помилки: збереження токена в chrome.storage.sync, відсутність перевірки терміну закінчення, використання одних і тих же токенів для різних користувачів. Ми виправляємо це на етапі code review — у 95% проєктів знаходимо хоча б одну критичну проблему.

Що входить у роботу під ключ

• Проєктування схеми авторизації (OAuth2 / JWT / власний сервер)
• Реалізація OAuth2 flow через chrome.identity або custom redirect
• TokenManager з автооновленням refresh-токенів
• UI popup-форми авторизації та панелі користувача
• Тестування на всіх Chrome-браузерах (Chrome, Edge, Opera, Yandex)
• Документація та передача вихідного коду
• Гарантія на впровадження до 3 місяців

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

Реалізація авторизації під ключ займає від 3 до 10 робочих днів залежно від складності (кількість провайдерів, кастомний сервер, особливі вимоги). Точну ціну та терміни розраховуємо індивідуально після аналізу вашого проєкту.

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

Аутентифікація та авторизація: 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 тижнів.

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