Интеграция Keycloak для аутентификации на сайте — SSO, OIDC, LDAP

Facepalm: очередной проект с самописной аутентификацией. Каждый из пяти микросервисов тащит свою базу хэшей паролей. OAuth завёрнут в костыли на PHP и Node.js. Мы видим это сплошь и рядом в legacy-системах. Такая архитектура плодит N+1 таблицу сессий, уязвимости в JWT (нет ротации ключей) и отсутствие единого входа между сервисами. Средняя экономия на лицензиях при миграции с Auth0 или Okta составляет 60–80%.

Keycloak — open-source Identity and Access Management от Red Hat. Self-hosted аналог Auth0 и Okta, поддерживает OpenID Connect, OAuth 2.0, SAML 2.0. Мы используем Keycloak в продакшене более 5 лет, развернули 15+ промышленных кластеров. Аутентификация работает без сбоев даже при 10 000 RPS. Свяжитесь с нами — бесплатно проанализируем вашу IAM-инфраструктуру.

Почему Keycloak лучше самописной аутентификации?

В самописных решениях типичные проблемы: N+1 таблица сессий, уязвимости в JWT (отсутствие ротации), отсутствие SSO между сервисами. Keycloak решает их из коробки:

• Единый реестр пользователей — не дублируем данные в каждом приложении
• Автоматическая ротация ключей подписи JWT — снижаем риск компрометации
• Поддержка LDAP/AD — сотрудники входят с корпоративными логинами
• Брокер социальных сетей — OAuth для Google/GitHub без лишнего кода

Кроме того, Keycloak предоставляет готовый UI аутентификации: страницы логина, саморегистрация, сброс пароля, MFA. Всё настраивается через админку. Разработчик концентрируется на бизнес-логике, а не на написании кучи middleware.

Сравнение Keycloak и самописной реализации

Как настроить LDAP-интеграцию?

В Keycloak Admin Console:

• User Federation → Add provider → LDAP
• Указать Connection URL, Bind DN, Users DN
• Настроить маппинг атрибутов: CN → username, mail → email

После настройки сотрудники входят с корпоративными логинами напрямую через Keycloak. Это особенно важно для компаний с Active Directory. Процесс занимает 1–2 дня и не требует изменений в приложениях.

Развёртывание Keycloak: Docker и настройка

Рекомендуем использовать Docker Compose для поднятия Keycloak с PostgreSQL:

version: '3.8'
services:
  keycloak:
    image: quay.io/keycloak/keycloak:latest
    environment:
      - KEYCLOAK_ADMIN=admin
      - KEYCLOAK_ADMIN_PASSWORD=admin
      - KC_DB=postgres
      - KC_DB_URL=jdbc:postgresql://postgres:5432/keycloak
      - KC_DB_USERNAME=keycloak
      - KC_DB_PASSWORD=password
    ports:
      - '8080:8080'
    depends_on:
      - postgres
  postgres:
    image: postgres:15
    environment:
      - POSTGRES_DB=keycloak
      - POSTGRES_USER=keycloak
      - POSTGRES_PASSWORD=password

После запуска переходим в админку, создаём realm и клиента.

Настройка Realm и Client

1. Создать Realm (логически изолированная область аутентификации)
2. Создать Client для веб-приложения:
   • Client type: OpenID Connect
   • Client authentication: On (confidential)
   • Valid redirect URIs: https://yourdomain.com/auth/callback
   • Valid post logout redirect URIs: https://yourdomain.com
3. Сохранить Client ID и Client Secret (Credentials tab)

Интеграция с Laravel через Socialite

// config/services.php
'keycloak' => [
    'client_id' => env('KEYCLOAK_CLIENT_ID'),
    'client_secret' => env('KEYCLOAK_CLIENT_SECRET'),
    'redirect' => env('KEYCLOAK_REDIRECT_URI'),
    'base_url' => env('KEYCLOAK_BASE_URL'), // e.g. http://localhost:8080
    'realm' => env('KEYCLOAK_REALM'),
],

// Socialite driver
use Socialite;

$user = Socialite::driver('keycloak')->user();

Прямая верификация JWT (для API)

Keycloak публикует JWKS по стандартному URL. API может проверять JWT напрямую без обращения к Keycloak:

use Firebase\JWT\JWK;
use Firebase\JWT\JWT;

$jwks = json_decode(file_get_contents('https://keycloak/auth/realms/{realm}/protocol/openid-connect/certs'), true);
$keys = JWK::parseKeySet($jwks);
$decoded = JWT::decode($token, $keys, ['RS256']);

Logout

Keycloak поддерживает front-channel и back-channel logout (RP-Initiated Logout):

$redirectUri = 'https://yourdomain.com';
$logoutUrl = 'https://keycloak/auth/realms/{realm}/protocol/openid-connect/logout?' . http_build_query([
    'id_token_hint' => $idToken,
    'post_logout_redirect_uri' => $redirectUri
]);
return redirect($logoutUrl);

Сроки и стоимость

Итого: 5–7 рабочих дней. Стоимость рассчитывается индивидуально — зависит от сложности и дополнительных требований. Закажите консультацию — мы бесплатно оценим ваш проект и пришлём коммерческое предложение.

Что входит в результат

• Рабочая инфраструктура Keycloak (Docker Compose, SSL, бэкапы)
• Realm с настроенными клиентами и ролями
• Интеграция с Laravel через Socialite (или любой фреймворк)
• JWT middleware для API
• LDAP/AD синхронизация (по запросу)
• Документация: схема потоков, описание настроек, скрипты деплоя
• Видеозапись обучения вашей команды (1 час)
• Поддержка 1 месяц (Telegram/почта)

Более 5 лет работаем с Keycloak, 15+ успешных интеграций. Сертифицированные специалисты Red Hat. Гарантируем: развернём Keycloak без простоев, настроим под ваш compliance, обучим команду. Свяжитесь с нами для оценки вашего проекта — мы бесплатно проанализируем вашу инфраструктуру и предложим оптимальное решение.

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