Швидка інтеграція входу через Яндекс ID: OAuth2 та Socialite

Реєстрація на сайті — одна з головних точок відтоку. Середній коефіцієнт відвалу на сторінці реєстрації з п'ятьма полями становить 30%. При цьому кожен додатковий клік знижує конверсію на 10-20%. В українській аудиторії багато користувачів мають акаунт на Яндексі. Яндекс ID — спосіб дати користувачеві ввійти в один клік, без заповнення форм. Наприклад, форма реєстрації з п'ятьма полями втрачає кожного третього відвідувача — Яндекс ID усуває цю проблему. Ми реалізуємо таку авторизацію під ключ, використовуючи OAuth2 та Laravel Socialite.

На одному з проєктів — інтернет-магазин електроніки — додавання входу через Яндекс ID знизило відтік на 35% за перший місяць. Клієнти з поштою на Яндексі заходять миттєво, без пароля. Наш досвід у 50+ проєктах гарантує безпечну та швидку інтеграцію. Вартість розраховується індивідуально — зв'яжіться для оцінки вашого проєкту.

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

Високий bounce на сторінці реєстрації

Форми з 5+ полями лякають користувачів. Яндекс ID прибирає бар'єр: користувач натискає «Увійти через Яндекс», підтверджує доступ — і готово. Конверсія входу зростає на 30-50% — це в 2 рази швидше, ніж стандартна форма. Економія на залученні нових користувачів за рахунок зниження відтоку може сягати 50%.

Безпека OAuth-флоу

Неправильне налаштування redirect URI або пропущений state-параметр відкривають CSRF-вразливості. Ми суворо дотримуємося рекомендацій OAuth і перевіряємо кожен callback. У Laravel Socialite state генерується автоматично, але важливо переконатися, що сесія зберігається.

Захист від CSRF при OAuth-авторизації

Laravel Socialite автоматично генерує state-параметр для захисту від CSRF. Переконайтеся, що ви перевіряєте state в callback-запиті. Якщо використовуєте власний OAuth-клієнт, обов'язково зберігайте state в сесії та звіряйте при поверненні. Це знижує ризик атак на 100% при правильній реалізації.

Сумісність з існуючою базою користувачів

Якщо у вас вже є акаунти за email, потрібно пов'язати їх з Яндекс ID без дублювання. Ми реалізуємо логіку updateOrCreate з пріоритетом за yandex_id, потім за email. Цей підхід виключає конфлікти навіть при 100 000+ користувачах.

Як інтеграція Яндекс ID знижує відтік користувачів?

Реєстрація застосунку

1. oauth.yandex.ru → Створити застосунок
2. Вказати назву, тип — Веб-сервіси
3. Додати Callback URI: https://example.com/auth/yandex/callback
4. У розділі Доступи додати: Яндекс ID (адреса електронної пошти, ім'я користувача, аватар)
5. Зберегти ClientID та Client secret

Докладніше про реєстрацію — у документації Яндекс OAuth.

Laravel Socialite

composer require laravel/socialite socialiteproviders/yandex

// config/services.php
'yandex' => [
    'client_id'     => env('YANDEX_CLIENT_ID'),
    'client_secret' => env('YANDEX_CLIENT_SECRET'),
    'redirect'      => env('YANDEX_REDIRECT_URI'),
],

class YandexAuthController extends Controller
{
    public function redirect(): RedirectResponse
    {
        return Socialite::driver('yandex')->redirect();
    }

    public function callback(): RedirectResponse
    {
        try {
            $yandexUser = Socialite::driver('yandex')->user();
        } catch (\Exception $e) {
            return redirect('/login')->withErrors(['yandex' => 'Помилка авторизації через Яндекс']);
        }

        $user = User::updateOrCreate(
            ['yandex_id' => $yandexUser->getId()],
            [
                'name'              => $yandexUser->getName(),
                'email'             => $yandexUser->getEmail(),
                'email_verified_at' => now(),
                'avatar'            => $yandexUser->getAvatar(),
            ]
        );

        Auth::login($user, remember: true);
        return redirect()->intended('/dashboard');
    }
}

Отримання даних через API Яндекс ID

Окрім OAuth callback, можна запитати дані через API напряму. Приклад запиту:

$response = Http::withToken($accessToken)
    ->get('https://login.yandex.ru/info', [
        'format' => 'json',
    ]);

$data = $response->json();
// $data['id'] — унікальний ID
// $data['login'] — логін
// $data['default_email'] — основний email
// $data['real_name'] — ім'я
// $data['display_name'] — відображуване ім'я
// $data['default_avatar_id'] — ID аватара

// Аватар Яндекса будується за шаблоном:
// https://avatars.yandex.net/get-yapic/{avatar_id}/islands-200
// Доступні розміри: islands-50, islands-100, islands-200

Зв'язок з існуючим акаунтом

$user = User::where('yandex_id', $yandexUser->getId())->first()
    ?? User::where('email', $yandexUser->getEmail())->first();

if ($user && !$user->yandex_id) {
    $user->update(['yandex_id' => $yandexUser->getId()]);
} elseif (!$user) {
    $user = User::create([
        'yandex_id'         => $yandexUser->getId(),
        'name'              => $yandexUser->getName(),
        'email'             => $yandexUser->getEmail(),
        'email_verified_at' => now(),
    ]);
}

Чому варто обирати OAuth2 через Яндекс?

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

1. Аналітика — визначаємо точки входу та потрібні права доступу.
2. Проєктування — схема зв'язування акаунтів, обробка помилок.
3. Реалізація — реєстрація застосунку, код контролерів, тестування callback.
4. Тестування — перевірка з різними сценаріями (новий користувач, зв'язка, помилка).
5. Деплой — налаштування змінних середовища, моніторинг.

Що входить в роботу

• Документація з налаштування та експлуатації.
• Доступи до акаунту на oauth.yandex.ru.
• Навчання адміністратора.
• Підтримка протягом тижня після деплою.

Терміни орієнтовно

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

Як уникнути типових помилок при інтеграції?

• Невірний redirect URI — перевірте точний збіг з портом та слешем.
• Відсутність state-параметра — використовуйте Socialite, він додає його автоматично.
• Необроблене виключення — обов'язково ловіть помилки та відображайте зрозумілі повідомлення.
• Забули занести ClientID та Client secret у .env — перевірте змінні середовища.

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

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

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