Прив'язка соцмереж до акаунту: 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 день. Замовте консультацію та переконайтеся в якості наших рішень.