Прив'язка соцмереж до акаунту: Account Linking на сайті

Чому прив'язка соцмереж критична для утримання користувачів?

Уявіть: користувач реєструвався через email, а через рік забув пароль. Або в нього два акаунти — один через Google, інший через email, і він хоче їх об'єднати. За статистикою, до 40% користувачів, які забули пароль, не повертаються на сайт. Без Account Linking ви або втрачаєте користувача, або змушуєте проходити виснажливу процедуру відновлення. Головні технічні складнощі — безпечно підтвердити власника, уникнути CSRF при OAuth 2.0-редиректах та не допустити блокування акаунту.

Ми реалізуємо прив'язку соцмереж (Google, GitHub, Apple) до існуючого облікового запису із захистом від цих ризиків. Наш досвід — понад 50 проектів. Самостійна реалізація займає в середньому 2–3 тижні, наше впровадження — від 3 до 6 днів, що в 3–5 разів швидше. Економія бюджету на розробку — до 60%. Економія на підтримці — близько 30% трудозатрат. Оцінимо ваш проект за 1 день. Гарантуємо захист від CSRF та безпечне зберігання токенів.

Прив'язка соцмереж: як уникнути втрати користувачів

Захист OAuth flow від CSRF — прив'язка соцмереж до

Кожен запит на прив'язку генерує унікальний state-параметр, який містить userId, назву провайдера та мітку дії (link). State шифрується та підписується, тому зловмисник не зможе підмінити користувача. У callback розшифровуємо state та звіряємо його з сесією — при неспівпадінні редирект на сторінку з помилкою. Цей підхід відповідає рекомендаціям OAuth 2.0 Authorization Framework, RFC 6749.

Чому не можна відв'язати єдиний спосіб входу?

Без цієї перевірки користувач може випадково заблокувати себе, відв'язавши останній метод. У нашій реалізації перед видаленням ми рахуємо кількість прив'язаних провайдерів та перевіряємо наявність passwordHash. Якщо залишиться 0 способів — операція відхиляється з повідомленням. Це стандартна best practice, яку ми закладаємо в архітектуру.

Проблеми, які вирішуємо

• CSRF-атаки при OAuth-редиректах — використовуємо state з підписом.
• Дублювання прив'язки — унікальний індекс provider + providerAccountId. Якщо акаунт вже прив'язаний до іншого користувача, повертаємо помилку account_already_linked.
• Блокування акаунту — заборона відв'язувати єдиний спосіб входу.
• Конфлікт даних — якщо email провайдера відрізняється від email облікового запису, не зливаємо їх автоматично, а зберігаємо providerEmail окремо для інформування.
• Відсутність єдиного входу (SSO) — реалізуємо повноцінну авторизацію через соцмережі з можливістю подальшої прив'язки до основного акаунту.

Як ми це робимо: стек та реалізація

Використовуємо Next.js 14 з App Router, NextAuth.js для сесій, Prisma ORM, PostgreSQL. Для OAuth-потоку застосовуємо code flow з PKCE. Серверні actions для ініціації прив'язки та відв'язки — все виконується на стороні сервера, без токенів на клієнті.

Схема даних:

model User {
  id           String   @id @default(cuid())
  email        String   @unique
  passwordHash String?
  linkedAccounts LinkedAccount[]
  createdAt    DateTime @default(now())
  updatedAt    DateTime @updatedAt
}

model LinkedAccount {
  id               String   @id @default(cuid())
  userId           String
  provider         String   // google, github, apple
  providerAccountId String
  accessToken      String?
  refreshToken     String?
  expiresAt        DateTime?
  user             User     @relation(fields: [userId], references: [id])
  createdAt        DateTime @default(now())
  updatedAt        DateTime @updatedAt

  @@unique([provider, providerAccountId])
}

Кейс із практики: клієнт — SaaS-платформа з 10 000 користувачів. Після впровадження прив'язки соціальних мереж кількість втрачених акаунтів знизилась на 40%. Розробка зайняла 3 дні, інтеграція з GitHub та Google — ще 2 дні на тестування edge-кейсів. Економія на підтримці — близько 30% трудозатрат.

Порівняння провайдерів OAuth

Процес роботи

1. Аналітика (1 день) — які провайдери, вимоги до даних, обговорення UX.
2. Проектування (0.5 дня) — схема БД, API endpoints, OAuth callback.
3. Реалізація (1–3 дні) — server actions, callback, UI-компонент керування. Пишемо код із захистом від race condition (транзакції).
4. Тестування (0.5–1 день) — юніт-тести для серверних функцій, інтеграційні тести OAuth flow (з mock-провайдерами).
5. Деплой та документація (0.5 дня) — розгортання на staging, перевірка в production-подібному оточенні, передача доступу до репозиторію.

Строки орієнтовно

Вартість розраховується індивідуально в залежності від кількості провайдерів та складності інтеграції.

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

• Схема бази даних та міграції.
• Server actions для прив'язки/відв'язки.
• OAuth callback з обробкою помилок.
• UI-компонент керування акаунтами.
• Unit- та інтеграційні тести.
• Документація з розгортання та підтримки.
• Допомога з деплоєм протягом 2 тижнів після здачі.

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

• Не перевіряти state в callback — діра для CSRF.
• Зберігати refresh token в localStorage — витік. Використовуємо httpOnly cookies.
• Не враховувати сценарій, коли користувач вже авторизований через провайдера, але з іншим email. У цьому випадку прив'язка може призвести до плутанини.
• Дозволяти відв'язку без перевірки інших способів входу. Результат — заблокований акаунт.
• Ігнорувати вимогу HTTPS для OAuth-редиректів.

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

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

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