Authentik vs Keycloak для корпоративного SSO: что выбрать SMB в 2026

За 2025–2026 годы наша команда перевела на SSO 12 клиентов: в шести случаях ставили Authentik, в пяти — Keycloak, один кейс был на FreeIPA. Дальше — честное сравнение двух главных игроков рынка open-source идентификации для офисов на 30–80 рабочих мест: где их сильные стороны, а где трудности, на конкретном примере из практики — маркетинговое агентство с 45 РМ и 14 внутренними сервисами.

Зачем вообще SSO небольшому офису

Когда у сотрудника 2–3 сервиса — SSO избыточен. А когда их 8 и больше — его отсутствие превращается в ежедневный ад. У типичного клиента АйТи Фреш в 2026-м:

• Почта и календарь (Nextcloud Mail или Zimbra).
• Файлы (Nextcloud, Seafile).
• CRM (amoCRM, Битрикс24).
• 1С:Предприятие (веб-клиент).
• Таск-трекер (Kaiten, Yougile, self-hosted Redmine).
• Wiki (BookStack, Wiki.js, Outline).
• Видеозвонки (Nextcloud Talk, BigBlueButton, Jitsi).
• VPN (NetBird, WireGuard).
• Мониторинг (Grafana, Zabbix).
• Чат (Rocket.Chat, Mattermost).
• Репозиторий (Gitea, GitLab).
• CI/CD (Drone, Jenkins).

12 сервисов × 45 человек × регулярная смена паролей = бардак. А с SSO всё становится прозрачно:

• Один логин (обычно доменная учётка).
• 2FA централизованно, настраивается один раз.
• При увольнении HR отключает доменную запись — доступ пропадает ВСЕГДА и ВЕЗДЕ за минуту.
• Audit log всех попыток логина в одном месте.

Краткие портреты

Keycloak — проект Red Hat, написан на Java (Quarkus), самый зрелый open-source IdP. Им пользуются в энтерпрайзе — от банков до госсектора. Мощный и гибкий, но тяжёлый в установке и эксплуатации.

Authentik же — проект довольно молодой, появился в 2020 году. Он разработан на Python/Django, а интерфейс у него на TypeScript-UI. Изначально его позиционировали как некую «простую open-source Okta», но вот с 2023-го он, надо сказать, сильно вырос и теперь по праву считается serious contender.

Детальное сравнение

Реальный опыт: как мы развернули Authentik у клиента

Клиент — маркетинговое агентство, 45 сотрудников, 14 сервисов. Хотелось «один логин на всё, и 2FA обязательно». Выбрали Authentik — за простоту UI и более скромные требования.

1. День 1. Подняли VPS 2 vCPU / 4 ГБ RAM / 40 ГБ SSD за 900 ₽/мес. Установили Authentik из официального docker-compose. За 40 минут получили рабочую админку.
2. День 2. Подключили Active Directory как Source через LDAP. Настроили синхронизацию: 45 пользователей подтянулись за 6 секунд. Включили правило «логин в Authentik = логин в AD» — пользователи вводят свои доменные пароли, которые никогда не уходят за пределы AD.
3. День 3. Подключили приложения по одному:
   • Nextcloud — OIDC, 5 минут на приложение.
   • GitLab Self-managed — OIDC, 10 минут (надо было чуть поправить scope).
   • Grafana — OIDC, 5 минут.
   • Gitea — OIDC, 5 минут.
   • Rocket.Chat — OAuth2, 10 минут.
   • BookStack — SAML2, 20 минут (SAML всегда менее приятен).
   • amoCRM — нет поддержки SSO в стандартной подписке, пришлось брать Pro-тариф.
   • NetBird VPN — OIDC, 5 минут.
   • Redmine (с плагином) — OIDC, 15 минут.
   • Wiki.js — OIDC, 5 минут.
   • Portainer — OIDC, 5 минут.
   • Proxmox — OIDC, 10 минут.
   • Synology NAS — SAML2, 30 минут (пляски с сертификатом).
   • Mattermost — SAML2, 20 минут.
4. День 4. Включили обязательный 2FA через TOTP (Google Authenticator). Провели обучение 45 сотрудников в двух группах — 1,5 часа каждая.

Что пошло не так и как исправили

• Outlook не дружит с OIDC без танцев. У части сотрудников (старые Outlook 2016) OIDC через браузер работал плохо — решили оставить им SMTP/IMAP с отдельным паролем приложения.
• 1С:Предприятие. Веб-клиент 1С имеет свою систему аутентификации, OIDC подключается только через прокси-трюк на nginx с auth_request. Мы сделали эту связку, но для клиентов «попроще» оставляем 1С в обход SSO.
• Сессии расходятся. По умолчанию сессия в Authentik — 8 часов, в Nextcloud — 15, в GitLab — 24. Результат: пользователь работает в GitLab, а в Nextcloud его выкидывает. Выровняли таймауты до 10 часов везде.
• Бэкапы Authentik. Забыли настроить регулярный бэкап PostgreSQL. На пятый день месяца всё упало, пришлось восстанавливаться из стандартной ежедневной копии VPS. Урок выучен — теперь делаем WAL-G в S3 на каждом Authentik-проекте.

Когда стоит взять Keycloak, а не Authentik

• Если у вас есть Java-разработчики, и вы планируете писать кастомные SPI (Service Provider Interfaces).
• Если нужно интегрироваться с Kerberos для Windows SSO без ввода пароля.
• Если корпоративная политика требует Red Hat-совместимую технологию.
• Если уже есть опыт с Keycloak в компании.
• Если планируется крупная мультитенантная инсталляция со сложными правилами авторизации.
• Если нужен fine-grained authorization (Keycloak UMA) — у Authentik это слабее.

Когда Authentik — правильный выбор

• SMB и средний бизнес до 200 РМ.
• Нет штатного Java-разработчика.
• Хочется простой UI и быстрого старта.
• Важно меньшее потребление ресурсов.
• Нужна актуальная документация и адекватная Matrix-чат-поддержка сообщества.
• Нужен встроенный Application Portal (пользовательский ландшафт, как в Okta).

Стоимость проектов

Что мы ведём на абонентке

• Подключение новых приложений по мере их появления у клиента.
• Управление группами и ролями при кадровых изменениях.
• Мониторинг работоспособности IdP (Authentik/Keycloak не должен лежать — иначе лежит всё).
• Обновление до новых версий после тестирования.
• Бэкап базы, проверка восстановления.
• Реакция на инциденты входа (пометки о подозрительных активностях).

Первый запуск: чем отличаются Authentik и Keycloak на практике

Authentik ставлю из официального compose-файла. Документация прямо называет этот способ вариантом для тестов и небольших продакшен-инсталляций и требует хост минимум с 2 ядрами CPU и 2 ГБ RAM. До первого запуска в .env кладу пароль PostgreSQL и секретный ключ:

wget https://docs.goauthentik.io/compose.yml
echo "PG_PASS=$(openssl rand -base64 36 | tr -d '\n')" >> .env
echo "AUTHENTIK_SECRET_KEY=$(openssl rand -base64 60 | tr -d '\n')" >> .env
docker compose pull
docker compose up -d

Пароль PostgreSQL длиннее 99 символов не поддерживается — это ограничение самой СУБД, о нём предупреждает документация. Внутри контейнера Authentik слушает 9000 (HTTP) и 9443 (HTTPS); наружу порты меняю переменными COMPOSE_PORT_HTTP и COMPOSE_PORT_HTTPS. После старта захожу на http://<сервер>:9000 и задаю пароль встроенного пользователя akadmin. Два момента проверяю сразу: не смонтированы ли в контейнеры /etc/timezone и /etc/localtime (Authentik работает в UTC, и подмена часового пояса ломает OAuth и SAML), и нужен ли worker-у доступ к Docker-сокету. Сокет монтируется для автоматического развёртывания outpost-ов; если outpost-ы не нужны, убираю монтирование или ставлю Docker Socket Proxy.

Keycloak запускается в двух режимах. kc.sh start-dev включает HTTP, отключает строгую проверку hostname и использует локальный кэш — только для проб. kc.sh start без настроенного hostname и TLS намеренно не стартует и выдаёт ошибку: это принцип secure by default. Поэтому к Keycloak я заранее готовлю сертификат, имя и обратный прокси, а консоль администратора публикую на отдельном hostname или пути и закрываю её снаружи — так советует руководство по продакшен-настройке.

Подключение Active Directory: какие параметры проверяю

В Authentik источник LDAP создаётся в разделе Directory → Federation and Social login. Что выставляю:

• Server URI — можно перечислить несколько контроллеров домена через запятую. Для LDAPS указываю порт 636, для StartTLS включаю отдельный флажок.
• TLS Verification Certificate — обязательно загружаю цепочку корпоративного CA. Если поле пустое, Authentik не проверяет сертификат контроллера вовсе и системное хранилище доверия не использует.
• Bind CN — служебная учётка с правом чтения, допустим формат UPN.
• Update internal password on login — по умолчанию выключено, и я так и оставляю: хеш доменного пароля в базе Authentik не хранится.
• При включённых Sync users и Sync groups нужно выбрать хотя бы одно сопоставление свойств, иначе синхронизация не запустится. Набор по умолчанию сделан под Active Directory.

В Keycloak решение, которое потом сложно отменить, — Edit Mode у провайдера LDAP. READ_ONLY запрещает менять атрибуты и пароль из Keycloak. WRITABLE пишет изменения обратно в каталог. UNSYNCED хранит изменения только в своей базе. Документация предупреждает: начальные мапперы создаются под выбранный режим и при его смене не перестраиваются. Поэтому режим выбираю при создании провайдера — для AD почти всегда READ_ONLY. Там же есть Periodic Full sync и Periodic Changed users sync, а вход по Kerberos без ввода пароля включается опцией Allow Kerberos authentication.

Мониторинг IdP: как понять, что вход сейчас работает

Если IdP лежит, не пускает никуда, поэтому проверки ставлю в Zabbix в первый же день. У Keycloak есть четыре эндпоинта здоровья — /health/started, /health/live, /health/ready и сводный /health. Они включаются опцией сборки --health-enabled=true и по умолчанию висят на порту управления 9000, а не на основном. Ответ 200 значит UP, 503 — сбой. Балансировщик направляю по /health/ready: пока идёт миграция базы при старте, этот эндпоинт отдаёт DOWN, и трафик на узел не пойдёт. Для Authentik дополнительно слежу за контейнерами server и worker и за резервной копией PostgreSQL — после истории с бэкапами выше это пункт номер один.

FAQ

Зачем SSO офису на 50 РМ?

Сотрудник каждое утро логинится в 7–12 разных сервисов. Без SSO это 12 паролей, половина слабых. SSO — один логин, 2FA, прозрачное отключение при увольнении.

Что лучше для SMB: Authentik или Keycloak?

Для офиса до 100 РМ — чаще Authentik: проще UI, легче установка, меньше RAM. Keycloak — мощнее, но требует больше опыта. Есть Java-разработчики — берите Keycloak.

Можно ли подружить с Active Directory?

Оба подтягивают пользователей из AD по LDAP. Логин в SSO идёт паролем из AD, блокировка доменной учётки = блокировка везде.

Сколько стоит внедрение?

Базовый SSO для 30–60 РМ с 5–7 приложениями — от 70 000 ₽, срок 3–4 дня. Каждое дополнительное приложение — 4 000–8 000 ₽.