Вход через Google с OAuth 2.0: руководство по настройке

Наша компания занимается разработкой, поддержкой и обслуживанием сайтов любой сложности. От простых одностраничных сайтов до масштабных кластерных систем построенных на микро сервисах. Опыт разработчиков подтвержден сертификатами от вендоров.

Разработка и обслуживание любых видов сайтов:

Информационные сайты или веб-приложения
Сайты визитки, landing page, корпоративные сайты, онлайн каталоги, квиз, промо-сайты, блоги, новостные ресурсы, информационные порталы, форумы, агрегаторы
Сайты или веб-приложения электронной коммерции
Интернет-магазины, B2B-порталы, маркетплейсы, онлайн-обменники, кэшбэк-сайты, биржи, дропшиппинг-платформы, парсеры товаров
Веб-приложения для управления бизнес-процессами
CRM-системы, ERP-системы, корпоративные порталы, системы управления производством, парсеры информации
Сайты или веб-приложения электронных услуг
Доски объявлений, онлайн-школы, онлайн-кинотеатры, конструкторы сайтов, порталы предоставления электронных услуг, видеохостинги, тематические порталы

Это лишь некоторые из технических типов сайтов, с которыми мы работаем, и каждый из них может иметь свои специфические особенности и функциональность, а также быть адаптированным под конкретные потребности и цели клиента

Услуги, которые мы предлагаем
Показано 1 из 1Все 2062 услуг
Вход через Google с OAuth 2.0: руководство по настройке
Простой
от 1 дня до 3 дней
Часто задаваемые вопросы

Наши компетенции:

Этапы разработки

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1358
  • image_web-applications_feedme_466_0.webp
    Разработка веб-приложения для компании FEEDME
    1250
  • image_websites_belfingroup_462_0.webp
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    956
  • image_ecommerce_furnoro_435_0.webp
    Разработка интернет магазина для компании FURNORO
    1188
  • image_crm_enviok_479_0.webp
    Разработка веб-приложения для компании Enviok
    929
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Разработка веб-сайта для компании ФИКСПЕР
    947

Проблема: пользователи не любят регистрироваться

Представьте: посетитель заходит на ваш сайт, хочет оставить комментарий или оформить заказ, но видит длинную форму регистрации — имя, 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

Параметр Редирект One Tap
UX Переход на страницу Google Попап без покидания сайта
Скорость 5–8 секунд 2–3 секунды
Конверсия Базовая Выше на 20–30%
Сложность Низкая (Socialite) Средняя (SDK + верификация)
Безопасность Высокая Высокая (проверка id_token)

Объём работ и сроки

Компонент Срок
Стандартный OAuth 2.0 (Socialite) 1–2 дня
+ One Tap +1 день
+ Объединение аккаунтов +1 день

Стоимость интеграции рассчитывается индивидуально, но экономия времени и бюджета за счёт готовых решений составляет до 40%. Оценим задачу за 24 часа — просто напишите.

Типичные ошибки при интеграции - Несовпадение redirect URI (включая завершающий слеш). - Истекший авторизационный код: обрабатывайте callback сразу. - Неправильная верификация id_token: используйте Google Client Library. - Отсутствие origin для One Tap в Authorized origins.

Почему стоит выбрать нас?

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

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

Аутентификация и авторизация: OAuth, JWT, сессии, RBAC, 2FA

На одном проекте токен JWT с ролью admin: false мог быть изменён клиентом на admin: true — сервер принимал его без верификации подписи. Это не гипотетическая атака: несколько файлов в npm-экосистеме имели уязвимость jwt библиотеки, которая игнорировала алгоритм none. Последствия — полный доступ к административным функциям для любого зарегистрированного пользователя.

JWT: что реально нужно знать

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 (симметричный) в микросервисной архитектуре: сервисы могут верифицировать токен публичным ключом, не имея доступа к секрету для его создания.

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 адаптера.

Сессии vs токены

Сессии хранят состояние на сервере (Redis, database) — сервер может мгновенно отозвать сессию. При масштабировании на несколько инстансов нужен общий store (Redis Cluster). Cookie с session ID — httpOnly, Secure, SameSite=Strict.

Stateless JWT не требуют server-side storage, масштабируются горизонтально. Но отзыв токена до истечения срока — только через blacklist (Redis), что частично убирает преимущество stateless.

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

RBAC и политики доступа

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.

Двухфакторная аутентификация

TOTP (Time-based One-Time Password, Google Authenticator, Authy) — стандарт. Библиотеки: otplib (Node.js), pragmarx/google2fa (Laravel). QR-код при подключении — base32-encoded secret, которого достаточно для воспроизведения кода при компрометации. Хранить secret в зашифрованном виде.

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

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

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

Типичные уязвимости

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: * — это дыра.

Процесс работы

Архитектура авторизации проектируется до начала разработки, не добавляется потом. Выбор между сессиями и JWT, структура ролей и прав, flow для OAuth-провайдеров, план для 2FA. Penetration testing обязателен для продуктов с финансовыми данными или персональными данными пользователей.

Сроки

Базовая аутентификация (email/password + OAuth + JWT/сессии): 1–3 недели. RBAC с детальными политиками доступа: 2–4 недели. 2FA (TOTP + SMS): 1–2 недели. WebAuthn/Passkeys: 2–3 недели. Полная система аутентификации для SaaS с multi-tenancy: 4–8 недель.