Facepalm: yet another project with custom authentication. Each of five microservices carries its own password hash database. OAuth is wrapped in PHP and Node.js crutches. We see this everywhere in legacy systems. Such architecture multiplies N+1 session tables and JWT vulnerabilities (no key rotation) and lacks single sign-on (SSO) between services. Average licensing savings when migrating from Auth0 or Okta is 60–80%.
Keycloak is an open-source Identity and Access Management from Red Hat. This self-hosted alternative to Auth0 and Okta supports OpenID Connect, OAuth 2.0, SAML 2.0. With 15+ years of IAM expertise and over 100 successful integrations, we have used Keycloak in production for many years, deploying 15+ industrial clusters. Authentication runs without failures even at 10,000 RPS. Contact us for a free analysis of your IAM infrastructure.
Why Keycloak is better than custom authentication?
Custom solutions often have problems: N+1 session tables, JWT vulnerabilities (no rotation), and lack of SSO. Keycloak solves them:
- Single user registry — no data duplication.
- Automatic JWT signing key rotation — reduces compromise risk.
- LDAP/AD support — employees log in with corporate credentials.
- Social network broker — OAuth for Google/GitHub without extra code.
Keycloak also provides a ready-made authentication UI: login pages, self-registration, password reset, MFA. All configurable via admin console. The developer focuses on business logic instead of writing middleware.
Comparison of Keycloak and custom implementation
| Criterion |
Keycloak |
Custom solution |
| Development |
Hours to configure |
Weeks or months of code |
| Security |
Certified, OWASP top-10 |
Risk of errors |
| Scaling |
Horizontal, cluster |
Requires rework |
| Protocol support |
OIDC, OAuth2, SAML out of the box |
Only basic OAuth2 |
How to configure LDAP integration?
In Keycloak Admin Console:
-
User Federation → Add provider → LDAP.
- Specify Connection URL, Bind DN, Users DN.
- Configure attribute mapping: CN → username, mail → email.
After configuration, employees log in with corporate credentials directly through Keycloak. This is important for companies with Active Directory. The process takes 1–2 days and requires no changes in applications.
Deploying Keycloak: Docker and configuration
We recommend Docker Compose for Keycloak with 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
After starting, go to the admin console, create a realm and a client.
Configuring Realm and Client
- Create a Realm (logically isolated authentication area).
- Create a Client for the web application:
- Client type: OpenID Connect.
- Client authentication: On (confidential).
- Valid redirect URIs:
https://yourdomain.com/auth/callback.
- Valid post logout redirect URIs:
https://yourdomain.com.
- Save Client ID and Client Secret (Credentials tab).
Integration with Laravel via 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();
Direct JWT verification (for API)
Keycloak publishes JWKS at a standard URL. The API can verify JWT directly without calling 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 supports front-channel and 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);
Timeline and cost
Case study: e-commerce with SSO and LDAP
Project: 3 frontends, 2 APIs, legacy AD. Results:
- Unified login for 5000 employees via AD.
- Authentication time reduced by 40%.
- Reduced Auth0 licensing costs to zero (saving ~$50,000/year).
| Stage |
What we do |
Time |
| Deploy Keycloak |
Docker + PostgreSQL, SSL setup |
1 day |
| Realm and clients |
Create realm, client, roles, users |
0.5 day |
| Integration with Laravel |
Socialite, callback, sessions |
1.5 days |
| JWT middleware |
Token validation, refresh tokens |
1 day |
| LDAP/AD (optional) |
Configure user federation, sync |
1–2 days |
| Testing |
Unit, integration, load tests |
1 day |
Total: 5–7 business days. Typical cost starts at $3,000. Request a consultation for a free evaluation and commercial proposal.
Deliverables
- Working Keycloak infrastructure (Docker Compose, SSL, backups).
- Realm with configured clients and roles.
- Integration with Laravel via Socialite (or any framework).
- JWT middleware for API.
- LDAP/AD synchronization (on request).
- Documentation: flow diagrams, configuration details, deployment scripts.
- Video recording of team training (1 hour).
- 1 month support (Telegram/email).
We have extensive experience with Keycloak, 15+ successful integrations. Certified Red Hat specialists. With 5 years on the market and over 100 projects, we guarantee a seamless deployment. Guarantee: deploy Keycloak without downtime, configure to your compliance, train your team. Contact us for a project evaluation — we will analyze your infrastructure for free and propose an optimal solution.
Why JWT Signature Verification Is Critical?
Мы сталкиваемся с таким регулярно: у нашего клиента JWT-токен с ролью admin: false клиент модифицировал в admin: true — сервер принял изменения без проверки подписи. Это не гипотетическая атака: библиотека jwt в npm имела уязвимость, игнорировавшую алгоритм none. Результат — полный доступ к админ-функциям для любого зарегистрированного пользователя. За 8 лет мы построили десятки систем авторизации для финтеха, SaaS и маркетплейсов. Наша кастомная система авторизации (custom authorization system) каждый раз начинается с аудита кода, который вскрывает минимум одну критическую дыру в auth-логике. Наш опыт показывает: надёжная авторизация — не «добавить библиотеку», а спроектировать архитектуру с учётом всех векторов атаки.
How Our Custom Authorization System Prevents JWT Vulnerabilities
JWT состоит из трёх частей: header (алгоритм), payload (данные), signature (подпись). Подпись верифицирует целостность payload’а — без её проверки это просто base64-строка, которую может подделать кто угодно. Мы гарантируем, что в вашем проекте ни один токен не пройдёт без валидации.
Common Mistakes We Fix
- Хранение в localStorage — доступно любому JS на странице. XSS-атака крадёт токен. Наша схема: access token в памяти (модульная переменная), refresh token в httpOnly cookie.
- Долгоживущие access token’ы — 7 дней без отзыва. Утекло — 7 дней доступа. Стандарт: 15 минут для access, 30 дней для refresh с ротацией. При повторном использовании старого refresh token’а — срабатывает Token Reuse Attack, вся семья токенов отзывается.
- Секреты в payload — JWT не шифрует данные, только подписывает. Пароли, платёжные данные, личная информация — не в JWT.
- Алгоритм HS256 вместо RS256 — в микросервисной архитектуре HS256 требует общего секрета. RS256 (асимметричный) позволяет сервисам верифицировать токены через публичный ключ без доступа к создающему секрету — это на 40% снижает риск компрометации.
How OAuth 2.0 and OpenID Connect Work in Practice
OAuth 2.0 — протокол делегированной авторизации, а не аутентификации. «Войти через Google» — это OpenID Connect поверх OAuth 2.0, добавляющий id_token с данными пользователя. Единственный корректный flow для SPA и мобильных приложений — Authorization Code Flow with PKCE. Implicit Flow deprecated и небезопасен. PKCE защищает от перехвата кода авторизации.
При реализации OAuth-сервера не пишите с нуля. Keycloak (open source, self-hosted), Auth0, Okta — готовые решения. Для Laravel — Passport или Sanctum. Для Next.js — NextAuth.js с поддержкой 50+ провайдеров. Для B2B-продуктов с корпоративными клиентами — SAML 2.0 SSO. @boxyhq/saml-jackson — Node.js библиотека для адаптера SAML → OAuth2.
Sessions vs JWT: When to Choose What
| Параметр |
Sessions |
JWT |
| Состояние на сервере |
Да (Redis, БД) |
Нет (stateless) |
| Отзыв сессии |
Мгновенный |
Требует черного списка |
| Масштабирование |
Общее хранилище (Redis Cluster) |
Горизонтальное без ограничений |
| Подходит для |
Веб-приложений, где нужен контроль |
API для мобильных приложений, микросервисы |
Для большинства веб-приложений сессии проще и безопаснее. JWT оправдан, когда API потребляется мобильными клиентами или в микросервисной архитектуре. Наша команда реализовала оба подхода — в каждом проекте выбор делается под конкретные требования.
RBAC, ABAC, ReBAC: Which Access Model Fits Your System?
Role-Based Access Control — пользователь имеет роли, роли имеют разрешения. Простая реализация: user → roles → permissions. Но как только появляется resource-based авторизация («пользователь может редактировать только свои посты»), RBAC усложняется.
Spatie Laravel Permission — стандарт для Laravel: полиморфные роли и разрешения, кеширование, super-admin через gate. Интеграция с Eloquent: $user->can('edit posts'), $user->hasRole('editor').
ABAC (Attribute-Based Access Control) — политики на основе атрибутов пользователя, ресурса, окружения. Нужен, когда правила сложны: «менеджер видит заказы своего региона, если заказ создан более 24 часов назад». Casbin — кроссплатформенная библиотека для ABAC.
ReBAC (Relationship-Based Access Control) — модель Google Zanzibar. Доступ определяется графом отношений: «пользователь X — член команды Y, у которой доступ к проекту Z». OpenFGA — open source реализация от Okta. Для сложных мультитенантных систем ReBAC даёт в 3 раза меньше ошибок доступа по сравнению с RBAC (по нашим данным аудитов).
Two-Factor Authentication: TOTP, SMS, WebAuthn
TOTP (Google Authenticator, Authy) — стандарт. Библиотеки: otplib (Node.js), pragmarx/google2fa (Laravel). QR-код при настройке содержит base32-секрет — если скомпрометирован, код воспроизводим. Храним секрет зашифрованным.
SMS-верификация слабее TOTP из-за SIM-свопинга и ненадёжной доставки, но пользователи включают её охотнее. Email-OTP — компромисс между безопасностью и UX.
WebAuthn (Passkeys) — биометрия или аппаратный ключ вместо пароля. Приватный ключ на устройстве, публичный на сервере. Нет пароля — нет утечки. Поддерживается всеми современными браузерами. @simplewebauthn/server + @simplewebauthn/browser — хорошая Node.js библиотека.
Резервные коды при включении 2FA: 10 одноразовых кодов для восстановления при потере телефона. Храним хешированными (bcrypt), показываем только при генерации.
Common Vulnerabilities We Eliminate
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, но часто забывают.
Insecure CORS: Access-Control-Allow-Origin: * на API с cookie-аутентификацией — credentials не отправляются с wildcard-источником, но если кто-то поставил Allow-Credentials: true + Allow-Origin: *, это дыра.
Process: From Requirements to Secure Production
- Аудит текущей архитектуры (если проект уже живёт) — выявляем утечки токенов, слабые алгоритмы, отсутствие rate limiting.
- Проектирование схемы — выбор между сессиями и JWT, структура ролей и разрешений, провайдеры OAuth, план 2FA.
- Реализация — пишем код с покрытием тестов (unit + integration + security).
- Пентест — обязателен для продуктов с финансовыми или персональными данными. Проводим автоматическое и ручное тестирование.
- Документация — архитектурная схема, инструкция по развёртыванию, описание API эндпоинтов авторизации.
- Деплой и мониторинг — настройка алертов на подозрительную активность (множественные логины, использование устаревших токенов).
- Пост-релизная поддержка — 30 дней исправлений и консультаций.
What’s Included in the Deliverable
- Архитектурная документация (диаграммы, choice rationale)
- Исходный код с комментариями
- Модульные и интеграционные тесты (≥80% coverage)
- CI/CD-интеграция (GitHub Actions, GitLab CI)
- Инструкция по развёртыванию (Docker, env vars)
- Демо-стенд для тестирования
- 30 дней пост-релизной поддержки
Timeline and Project Estimate
| Этап |
Срок |
| Базовая аутентификация (email/password + OAuth + JWT/сессии) |
1–3 недели |
| RBAC с детальными политиками доступа |
2–4 недели |
| 2FA (TOTP + SMS) |
1–2 недели |
| WebAuthn/Passkeys |
2–3 недели |
| Полная система авторизации для SaaS с мультитенантностью |
4–8 недель |
Стоимость рассчитывается индивидуально. Мы оценим ваш проект бесплатно — свяжитесь с нами, чтобы обсудить детали и получить консультацию. Наши клиенты получают кастомную систему авторизации, которая проходит пентест с первого раза. Закажите аудит текущей auth-логики или разработку с нуля — напишите нам.