Вхід через Google з OAuth 2.0: керівництво з налаштування

Проблема: користувачі не люблять реєструватися

Уявіть: відвідувач заходить на ваш сайт, хоче залишити коментар або оформити замовлення, але бачить довгу форму реєстрації — ім'я, email, пароль, підтвердження пароля, капча... 90% йдуть. Google OAuth 2.0 вирішує це: один клік — і користувач всередині. Але між ідеєю та робочою реалізацією — кілька підводних каменів: невірний redirect URI, помилки верифікації токена, плутанина з прив'язкою акаунтів. Ми реалізували цю схему для 50+ проєктів і зібрали робочий рецепт.

На одному з проєктів (SaaS-платформа з 50 000+ користувачів) традиційна реєстрація давала конверсію лише 12%, а після впровадження One Tap вона зросла до 34% — користувачі перестали кидати форму.

Ми використовуємо перевірені інструменти: Laravel Socialite для швидкого старту або Google Identity Services для сучасних сценаріїв. Наші інженери — спеціалісти з досвідом понад 6 років у цій галузі. У цій статті — готовий код, який стане у ваш проєкт.

Як працює OAuth 2.0 з Google?

Процес складається з трьох кроків:

1. Користувач натискає «Увійти через Google».
2. Перенаправлення на Google з параметрами client_id, redirect_uri та scope.
3. Google повертає авторизаційний код, сервер обмінює його на токен і перевіряє.

Помилка №1 — неспівпадіння redirect URI. У Google Cloud Console потрібно вказати точний URL, включаючи протокол і слеш. Інакше Google поверне redirect_uri_mismatch. Помилка №2 — закінчення терміну дії авторизаційного коду: він живе лише кілька хвилин, тому callback має оброблятися без затримок. Помилка №3 — неправильна верифікація id_token: ми використовуємо Google Client Library для перевірки підпису та терміну дії.

Що таке One Tap і як його підключити?

One Tap — це popup-вікно, яке з'являється на сторінці без перезавантаження. Користувач бачить пропозицію увійти через Google і підтверджує одним кліком. Це швидше за редирект у 2 рази (наприклад, для того ж SaaS-проєкту час входу скоротився з 8 до 3 секунд).

Для One Tap використовуємо Google Identity Services SDK. Токен (id_token) приходить у callback, сервер верифікує його через Google Client Library. На клієнті достатньо вставити скрипт і контейнер — код нижче.

Реєстрація OAuth-клієнта та перевірка

1. Google Cloud Console → APIs & Services → Credentials.
2. Створити OAuth 2.0 Client ID типу Web application.
3. Додати Authorized redirect URIs: https://example.com/auth/google/callback.
4. Зберегти Client ID і Client Secret.
5. Обов'язково додати Authorized origins: https://example.com для One Tap.

Як перевірити конфігурацію?

• Переконайтеся, що redirect URI збігається із зазначеним у консолі (включаючи слеш).
• Перевірте, що Client ID і Secret коректно підставлені в .env.
• Протестуйте callback за допомогою інструменту на кшталт Postman, відправивши GET-запит.
• Для One Tap: переконайтеся, що origin сервера додано в Authorized origins.

Код: Laravel Socialite (redirect + callback)

composer require laravel/socialite

// config/services.php
'google' => [
    'client_id'     => env('GOOGLE_CLIENT_ID'),
    'client_secret' => env('GOOGLE_CLIENT_SECRET'),
    'redirect'      => env('GOOGLE_REDIRECT_URI'),
],

// routes/web.php
Route::get('/auth/google',          [GoogleAuthController::class, 'redirect']);
Route::get('/auth/google/callback', [GoogleAuthController::class, 'callback']);

class GoogleAuthController extends Controller
{
    public function redirect(): RedirectResponse
    {
        return Socialite::driver('google')
            ->scopes(['openid', 'profile', 'email'])
            ->redirect();
    }

    public function callback(): RedirectResponse
    {
        $googleUser = Socialite::driver('google')->user();

        // Прив'язка до існуючого акаунту за email
        $user = User::where('google_id', $googleUser->getId())->first();
        if (!$user) {
            $user = User::where('email', $googleUser->getEmail())->first();
            if ($user) {
                $user->update(['google_id' => $googleUser->getId()]);
            } else {
                $user = User::create([
                    'google_id'         => $googleUser->getId(),
                    'name'              => $googleUser->getName(),
                    'email'             => $googleUser->getEmail(),
                    'email_verified_at' => now(),
                ]);
            }
        }

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

One Tap: клієнтська та серверна частина

<script src="https://accounts.google.com/gsi/client" async defer></script>
<div id="g_id_onload"
     data-client_id="{{ config('services.google.client_id') }}"
     data-callback="handleGoogleResponse"
     data-auto_prompt="false">
</div>
<div class="g_id_signin" data-type="standard"></div>

<script>
function handleGoogleResponse(response) {
    // response.credential — id_token (JWT)
    fetch('/auth/google/token', {
        method: 'POST',
        headers: { 'Content-Type': 'application/json', 'X-CSRF-TOKEN': csrfToken },
        body: JSON.stringify({ credential: response.credential }),
    }).then(r => r.json()).then(data => {
        if (data.redirect) window.location.href = data.redirect;
    });
}
</script>

use Google\Client as GoogleClient;

public function handleToken(Request $request): JsonResponse
{
    $client = new GoogleClient(['client_id' => config('services.google.client_id')]);
    $payload = $client->verifyIdToken($request->credential);

    if (!$payload) {
        return response()->json(['error' => 'Invalid token'], 401);
    }

    $user = User::updateOrCreate(
        ['google_id' => $payload['sub']],
        ['name' => $payload['name'], 'email' => $payload['email']]
    );

    Auth::login($user);
    return response()->json(['redirect' => '/dashboard']);
}

Порівняння: редирект-потік vs One Tap

Обсяг робіт і терміни

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

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

Наші інженери працюють з Google OAuth понад 6 років. Реалізували авторизацію для 50+ проєктів з аудиторією від 1 000 до 100 000 користувачів. Гарантуємо безпеку: використовуємо тільки перевірені бібліотеки та дотримуємося best practices. Під ключ — від реєстрації клієнта до налагодження в продакшені.

Все прозоро: ви отримуєте готовий код, документацію та чек-лист для моніторингу. Зв'яжіться, щоб обговорити ваш проєкт — ми оцінимо задачу за 24 години. Замовте інтеграцію Google OAuth у нас — отримайте консультацію та кошторис за 24 години.

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

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