Account Linking: Secure Social Login Integration

Why Social Account Linking Is Critical for User Retention

Imagine a user registered via email and a year later forgot the password. Or they have two accounts—one via Google, another via email—and want to merge them. Statistics show that up to 40% of users who forget their password never return to the site. Without Account Linking, you either lose the user or force them through a tedious recovery process. The main technical challenges are securely verifying ownership, avoiding CSRF during OAuth 2.0 redirects (see OAuth RFC), and preventing account lockouts.

We implement social login integration (Google, GitHub, Apple) to existing accounts with protection against these risks. Our experience spans over 50 projects. Self-implementation typically takes 2-3 weeks; our deployment takes 3 to 6 days—3-5 times faster. Development cost savings up to 60%, typically $10,000+ for a project with 2 providers. Support savings around 30% effort. We'll evaluate your project in 1 day. Guarantee CSRF protection and secure token storage.

Social Account Linking: Prevent User Loss

Protect OAuth Flow from CSRF

Each link request generates a unique state parameter containing userId, provider name, and action tag (link). The state is encrypted and signed, so an attacker cannot impersonate the user. On callback, we decrypt and verify the state against the session—mismatch redirects to an error page. This follows OAuth 2.0 Authorization Framework, RFC 6749.

Why Unlinking the Only Login Method Is Forbidden

Without this check, a user could accidentally lock themselves out by removing the last method. In our implementation, before unlinking we count linked providers and check for a passwordHash. If zero methods would remain, the operation is rejected with a message. This is a standard best practice we build into the architecture.

Problems We Solve

• CSRF attacks during OAuth redirects — we use signed state.
• Duplicate linking — unique index on provider + providerAccountId. If the account is already linked to another user, return error account_already_linked.
• Account lockout — forbid unlinking the only login method.
• Data conflict — if provider email differs from account email, we don't merge automatically; store providerEmail separately for information.
• No single sign-on (SSO) — we implement full social login with subsequent linking to the main account.

How We Do It: Tech Stack and Implementation

We use Next.js 14 with App Router, NextAuth.js for sessions, Prisma ORM, PostgreSQL. For OAuth flow we use code flow with PKCE. Server actions for initiating link/unlink—all server-side, no tokens on client.

Data schema:

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])
}

Real case: client — SaaS platform with 10,000 users. After implementing social account linking, lost accounts dropped by 40%. Development took 3 days, integration with GitHub and Google — another 2 days for edge-case testing. Support savings: about 30% effort.

OAuth Provider Comparison

Process

1. Analytics (1 day) — which providers, data requirements, UX discussion.
2. Design (0.5 day) — DB schema, API endpoints, OAuth callback.
3. Implementation (1-3 days) — server actions, callback, UI management component. Code with race condition protection (transactions).
4. Testing (0.5-1 day) — unit tests for server functions, integration tests for OAuth flow (with mock providers).
5. Deploy and documentation (0.5 day) — staging deployment, production-like environment check, repository access.

Estimated Timeline

Cost is calculated individually based on number of providers and integration complexity. For 2 social providers, typical project cost starts at $4,500.

What's Included in Turnkey Work

• Database schema and migrations.
• Server actions for link/unlink.
• OAuth callback with error handling.
• UI component for account management.
• Unit and integration tests.
• Deployment and support documentation.
• Deployment assistance for 2 weeks after delivery.

Common Mistakes in Self-Implementation

• Not verifying state in callback — CSRF vulnerability.
• Storing refresh token in localStorage — leakage; we use httpOnly cookies.
• Not handling scenario where user is already logged in via provider with a different email — linking can cause confusion.
• Allowing unlink without checking remaining login methods — results in locked account.
• Ignoring HTTPS requirement for OAuth redirects.

Avoid these problems with our implementation featuring a battle-tested architecture. Our social login integration and account linking solution is 5 times more efficient than in-house development. Contact us for a project evaluation—we'll prepare a proposal within 1 day. Request a consultation and see the quality of our solutions.

Why JWT Signature Verification Is Critical?

Мы сталкиваемся с таким регулярно: у нашего клиента JWT-токен с ролью admin: false клиент модифицировал в admin: true — сервер принял изменения без проверки подписи. Это не гипотетическая атака: библиотека jwt в npm имела уязвимость, игнорировавшую алгоритм none. Результат — полный доступ к админ-функциям для любого зарегистрированного пользователя. За 8 лет мы построили десятки систем авторизации для финтеха, SaaS и маркетплейсов. Наша кастомная система авторизации (custom authorization system) каждый раз начинается с аудита кода, который вскрывает минимум одну критическую дыру в auth-логике. Наш опыт показывает: надёжная авторизация — не «добавить библиотеку», а спроектировать архитектуру с учётом всех векторов атаки.

How Our Custom Authorization System Prevents JWT Vulnerabilities

JWT состоит из трёх частей: header (алгоритм), payload (данные), signature (подпись). Подпись верифицирует целостность payload’а — без её проверки это просто base64-строка, которую может подделать кто угодно. Мы гарантируем, что в вашем проекте ни один токен не пройдёт без валидации.

Common Mistakes We Fix

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

How OAuth 2.0 and OpenID Connect Work in Practice

OAuth 2.0 — протокол делегированной авторизации, а не аутентификации. «Войти через Google» — это OpenID Connect поверх OAuth 2.0, добавляющий id_token с данными пользователя. Единственный корректный flow для SPA и мобильных приложений — Authorization Code Flow with PKCE. Implicit Flow deprecated и небезопасен. PKCE защищает от перехвата кода авторизации.

При реализации OAuth-сервера не пишите с нуля. Keycloak (open source, self-hosted), Auth0, Okta — готовые решения. Для Laravel — Passport или Sanctum. Для Next.js — NextAuth.js с поддержкой 50+ провайдеров. Для B2B-продуктов с корпоративными клиентами — SAML 2.0 SSO. @boxyhq/saml-jackson — Node.js библиотека для адаптера SAML → OAuth2.

Sessions vs JWT: When to Choose What

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

RBAC, ABAC, ReBAC: Which Access Model Fits Your System?

Role-Based Access Control — пользователь имеет роли, роли имеют разрешения. Простая реализация: user → roles → permissions. Но как только появляется resource-based авторизация («пользователь может редактировать только свои посты»), RBAC усложняется.

Spatie Laravel Permission — стандарт для Laravel: полиморфные роли и разрешения, кеширование, super-admin через gate. Интеграция с Eloquent: $user->can('edit posts'), $user->hasRole('editor').

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

ReBAC (Relationship-Based Access Control) — модель Google Zanzibar. Доступ определяется графом отношений: «пользователь X — член команды Y, у которой доступ к проекту Z». OpenFGA — open source реализация от Okta. Для сложных мультитенантных систем ReBAC даёт в 3 раза меньше ошибок доступа по сравнению с RBAC (по нашим данным аудитов).

Two-Factor Authentication: TOTP, SMS, WebAuthn

TOTP (Google Authenticator, Authy) — стандарт. Библиотеки: otplib (Node.js), pragmarx/google2fa (Laravel). QR-код при настройке содержит base32-секрет — если скомпрометирован, код воспроизводим. Храним секрет зашифрованным.

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

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

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

Common Vulnerabilities We Eliminate

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, но часто забывают.

Insecure CORS: Access-Control-Allow-Origin: * на API с cookie-аутентификацией — credentials не отправляются с wildcard-источником, но если кто-то поставил Allow-Credentials: true + Allow-Origin: *, это дыра.

Process: From Requirements to Secure Production

1. Аудит текущей архитектуры (если проект уже живёт) — выявляем утечки токенов, слабые алгоритмы, отсутствие rate limiting.
2. Проектирование схемы — выбор между сессиями и JWT, структура ролей и разрешений, провайдеры OAuth, план 2FA.
3. Реализация — пишем код с покрытием тестов (unit + integration + security).
4. Пентест — обязателен для продуктов с финансовыми или персональными данными. Проводим автоматическое и ручное тестирование.
5. Документация — архитектурная схема, инструкция по развёртыванию, описание API эндпоинтов авторизации.
6. Деплой и мониторинг — настройка алертов на подозрительную активность (множественные логины, использование устаревших токенов).
7. Пост-релизная поддержка — 30 дней исправлений и консультаций.

What’s Included in the Deliverable

• Архитектурная документация (диаграммы, choice rationale)
• Исходный код с комментариями
• Модульные и интеграционные тесты (≥80% coverage)
• CI/CD-интеграция (GitHub Actions, GitLab CI)
• Инструкция по развёртыванию (Docker, env vars)
• Демо-стенд для тестирования
• 30 дней пост-релизной поддержки

Timeline and Project Estimate

Стоимость рассчитывается индивидуально. Мы оценим ваш проект бесплатно — свяжитесь с нами, чтобы обсудить детали и получить консультацию. Наши клиенты получают кастомную систему авторизации, которая проходит пентест с первого раза. Закажите аудит текущей auth-логики или разработку с нуля — напишите нам.