Авторизація через Однокласники: OAuth 2.0 + Laravel Socialite

Реалізація авторизації через Однокласники на сайті

Втрата 25% користувачів на етапі реєстрації — стандартна проблема для сайтів з аудиторією 35+. Однокласники — друга за охопленням соцмережа в Україні: 70 млн активних користувачів на місяць (дані VK Group). Відсутність авторизації через Однокласники змушує заповнювати довгі форми, конверсія падає. Особливо критично для регіональних проєктів та інтернет-магазинів, де аудиторія старше 40 років звикла входити через OK. Ми вирішуємо задачу за 1–2 дні: інтеграція OAuth 2.0 з підписом запитів за стандартом OK API.

Що дає авторизація через Однокласники?

Вхід через OK скорочує час реєстрації до 3 секунд. Користувач натискає одну кнопку — отримує доступ до профілю. Нам доступні: ім'я, аватар, email (за наявності прав). Це знижує відтік на 15% порівняно з формою реєстрації. Для регіональних проєктів і товарів для старшого покоління — канал із мінімальним тертям.

Як працює OAuth 2.0 в Однокласниках?

Протокол OAuth 2.0 з додатковим підписом запитів через session_secret_key. Клієнтський застосунок отримує токен доступу, який дозволяє запитувати дані профілю. Підпис обов'язковий для кожного виклику API — інакше сервер поверне помилку 403. OK API вимагає підпису кожного запиту: параметри сортуються, конкатенуються, потім хешуються разом із session_secret_key. Socialite-провайдер робить це автоматично, але при прямих викликах (наприклад, users.getInfo) потрібна ручна реалізація.

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

1. Перейдіть до кабінету розробника: ok.ru/dk?st.cmd=appcenter (офіційний портал).
2. Створіть зовнішній застосунок, вкажіть адресу сайту та дозволені redirect URI.
3. Отримайте параметри: App ID, Public key, Secret key.

Laravel Socialite

Встановіть пакет через Composer:

composer require laravel/socialite socialiteproviders/odnoklassniki

Додайте конфігурацію в config/services.php:

'odnoklassniki' => [
    'client_id'     => env('OK_APP_ID'),
    'client_secret' => env('OK_SECRET_KEY'),
    'client_public' => env('OK_PUBLIC_KEY'),
    'redirect'      => env('OK_REDIRECT_URI'),
],

Реалізуйте контролер:

class OkAuthController extends Controller
{
    public function redirect(): RedirectResponse
    {
        return Socialite::driver('odnoklassniki')
            ->scopes(['VALUABLE_ACCESS', 'GET_EMAIL'])
            ->redirect();
    }

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

        $user = User::updateOrCreate(
            ['ok_id' => $okUser->getId()],
            [
                'name'   => $okUser->getName(),
                'email'  => $okUser->getEmail() ?: null,
                'avatar' => $okUser->getAvatar(),
            ]
        );

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

Як налаштувати OAuth-потік вручну?

Якщо Socialite не підходить, реалізуйте протокол напряму. Після редиректу користувача на OK та отримання коду авторизації, обміняйте його на access_token через POST-запит до https://api.ok.ru/oauth/token.do. Потім запитайте дані через users.getCurrentUser, підписавши запит session_secret_key. Переконайтеся, що redirect URI збігається з указаним у налаштуваннях застосунку.

Чому підпис запитів важливий?

OK API унікальний тим, що вимагає підпису на кожен виклик. Це підвищує безпеку, але ускладнює інтеграцію. Підпис формується так: параметри сортуються за ключем, конкатенуються в рядок key1=value1key2=value2..., потім хешуються MD5 разом із session_secret_key (MD5 від access_token + secret_key). Якщо підпис невірний, API повертає помилку 403. Socialite-провайдер приховує цю складність, але знання механізму знадобиться при прямих запитах.

function signOkRequest(array $params, string $accessToken, string $secretKey): string
{
    ksort($params);
    $paramString = '';
    foreach ($params as $key => $value) {
        $paramString .= "{$key}={$value}";
    }

    // session_secret_key = MD5(access_token + secret_key)
    $sessionSecretKey = md5($accessToken . $secretKey);

    return md5($paramString . $sessionSecretKey);
}

Порівняння: вхід через OK vs. SMS-код

OAuth через Однокласники в 10 разів швидше SMS-коду: 3 секунди проти 30–60. Відмова користувача при вході через OK — 5%, тоді як при SMS-коді — 20%. Конверсія в реєстрацію — 85% проти 65%.

Доступні дані при авторизації через Однокласники

Email може бути відсутнім: рішення

Якщо користувач не прив'язав пошту до OK, поле email буде null. У цьому випадку запропонуйте користувачеві ввести email вручну після входу або використовуйте інший ідентифікатор для комунікації. На практиці email відсутній у 30–40% користувачів старше 50 років. Це не впливає на сам вхід — профіль створюється без email, а пошта запитується окремо.

Як обробляти помилки API?

При авторизації через Однокласники можливі помилки: таймаути (якщо OK не відповідає більше 30 секунд), скасування користувачем (користувач натиснув «Скасувати» в діалозі), невалідні токени (якщо access_token закінчився або підпис невірний). Рекомендуємо обгортати виклики в try-catch і повертати зрозуміле повідомлення: «Не вдалося увійти через Однокласники. Спробуйте ще раз або використайте інший спосіб». Логуйте деталі для налагодження.

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

• Реєстрація застосунку в кабінеті розробника OK
• Налаштування OAuth-потоку на стороні бекенда (Laravel або інший фреймворк)
• Обробка помилок: таймаути, скасування користувачем, невалідні токени
• Тестування на staging і production
• Документація за отриманими доступами

Строки та вартість

Базова інтеграція займає від 1 до 2 робочих днів. Вартість розраховується індивідуально залежно від складності проєкту (наприклад, якщо потрібен кастомний збір даних або інтеграція з legacy-авторизацією). Зв'яжіться з нами — ми оцінимо ваш проєкт безкоштовно.

Чому варто обрати нас?

Наш досвід — понад 20 проєктів з авторизацією через Однокласники: від невеликих інтернет-магазинів до регіональних порталів з аудиторією 500k+. Гарантуємо стабільну роботу та відповідність Core Web Vitals. Замовте інтеграцію — отримайте готове рішення під ключ. Отримайте консультацію: обговоримо ваш проєкт.

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

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