Keycloak или Authentik: что выгоднее и когда

MAATRIX

Если у вас пять-десять сервисов и для каждого свой пароль, рано или поздно кто-то заведёт учётку уволенного сотрудника в общей таблице Excel «на всякий случай» — и это станет дырой в безопасности. SSO-сервер решает проблему одним входом для всех приложений, но выбор между Keycloak и Authentik ставит в тупик: оба бесплатные, оба поддерживают OIDC и SAML, а документация обоих обещает «простую установку за 10 минут». На практике это не так, и цена ошибки — часы на миграцию realm или, хуже, простой продакшена в момент, когда никто не может залогиниться. Разберём, чем они на самом деле отличаются и когда переплата по железу оправдана.

Что это вообще такое и зачем нужно

Оба продукта — identity provider (IdP): единая точка, которая проверяет пароль (и второй фактор) один раз, а дальше выдаёт токены остальным приложениям по протоколам OIDC, OAuth2 и SAML. Вместо того чтобы Grafana, Nextcloud и внутренний CRM каждый хранили свою базу пользователей, они доверяют токенам от одного сервера.

Keycloak — проект, который Red Hat выкатила ещё в 2014 году (сейчас живёт под крылом CNCF), написан на Java поверх Quarkus. Это тяжеловес корпоративного мира: полноценная поддержка SAML 2.0 из коробки, federation с Active Directory и LDAP, тонкая настройка через Admin Console с сотнями галочек. Именно Keycloak чаще всего встречается в требованиях enterprise-заказчиков и в тендерах — не потому что он лучше технически, а потому что его знают аудиторы безопасности.

Authentik — проект помоложе (первый релиз в 2019), написан на Python (Django) с фронтендом на Go для outpost-прокси. Философия другая: минимум конфигурации через UI, максимум через flows — визуальные цепочки шагов аутентификации, которые можно кастомизировать программно. SAML тоже есть, но чувствуется, что это OIDC-first продукт для тех, кто ставит SSO перед self-hosted сервисами вроде Nextcloud, Gitea, Proxmox.

Прежде чем сравнивать — важная оговорка: ни один тест на этой странице не претендует на точный бенчмарк. Цифры по RAM и времени старта — ориентир по опыту эксплуатации на типовых VPS, у вас на конкретном железе и с конкретной нагрузкой они будут отличаться.

Требования к железу: honest-сравнение

Вот где расхождение самое ощутимое, и именно оно чаще всего решает выбор для небольшой команды.

Keycloak — это JVM-приложение, и здесь работают все знакомые джавистам грабли: heap нужно резервировать заранее (JAVA_OPTS_APPEND=-Xms512m -Xmx1024m), иначе на минимальном VPS в 1 ГБ он либо не стартует, либо начинает падать под нагрузкой при первом же всплеске сессий. На 2 ГБ RAM Keycloak уже чувствует себя нормально при десятке приложений и сотне пользователей.

Authentik легче в холостом режиме, но у него другая архитектура: сам server (Django/Gunicorn), worker для фоновых задач, Postgres и Redis — то есть минимум четыре контейнера вместо одного. Суммарно по памяти разница не так драматична, как кажется по документации, но по CPU при старте Authentik ощутимо экономнее.

Практический вывод: если у вас VPS на 1-2 ГБ RAM и только один-два защищаемых сервиса — Authentik стартует увереннее. Если вы уже держите сервер на 4 ГБ и выше под несколько бэкендов — разница стирается, и решает функциональность, а не ресурсы.

Установка: сколько шагов до первого логина

Оба ставятся через docker compose за 10-15 минут, если конфиг готов — реальная работа начинается после, на настройке realm/провайдера. Мы разбирали процесс пошагово в отдельных материалах: установка Keycloak на Ubuntu 24.04 и установка Authentik на Ubuntu 24.04.

Минимальный docker-compose.yml для Keycloak (production-режим с внешним Postgres):

services:
  postgres:
    image: postgres:16
    restart: unless-stopped
    environment:
      POSTGRES_DB: keycloak
      POSTGRES_USER: keycloak
      POSTGRES_PASSWORD: change_me_strong
    volumes:
      - kc_pgdata:/var/lib/postgresql/data

  keycloak:
    image: quay.io/keycloak/keycloak:26.0
    restart: unless-stopped
    command: start --optimized
    environment:
      KC_DB: postgres
      KC_DB_URL: jdbc:postgresql://postgres:5432/keycloak
      KC_DB_USERNAME: keycloak
      KC_DB_PASSWORD: change_me_strong
      KC_HOSTNAME: sso.example.com
      KC_PROXY_HEADERS: xforwarded
      KEYCLOAK_ADMIN: admin
      KEYCLOAK_ADMIN_PASSWORD: change_me_too
    depends_on:
      - postgres
    ports:
      - "127.0.0.1:8080:8080"

volumes:
  kc_pgdata:

Минимальный набор для Authentik (server + worker + Postgres + Redis):

services:
  postgresql:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      POSTGRES_DB: authentik
      POSTGRES_USER: authentik
      POSTGRES_PASSWORD: change_me_strong
    volumes:
      - ak_pgdata:/var/lib/postgresql/data

  redis:
    image: redis:alpine
    restart: unless-stopped
    volumes:
      - ak_redis:/data

  server:
    image: ghcr.io/goauthentik/server:2024.10
    restart: unless-stopped
    command: server
    environment:
      AUTHENTIK_SECRET_KEY: change_me_random_50_chars
      AUTHENTIK_POSTGRESQL__HOST: postgresql
      AUTHENTIK_POSTGRESQL__USER: authentik
      AUTHENTIK_POSTGRESQL__PASSWORD: change_me_strong
      AUTHENTIK_REDIS__HOST: redis
    ports:
      - "127.0.0.1:9000:9000"
    depends_on:
      - postgresql
      - redis

  worker:
    image: ghcr.io/goauthentik/server:2024.10
    restart: unless-stopped
    command: worker
    environment:
      AUTHENTIK_SECRET_KEY: change_me_random_50_chars
      AUTHENTIK_POSTGRESQL__HOST: postgresql
      AUTHENTIK_POSTGRESQL__USER: authentik
      AUTHENTIK_POSTGRESQL__PASSWORD: change_me_strong
      AUTHENTIK_REDIS__HOST: redis
    depends_on:
      - postgresql
      - redis

volumes:
  ak_pgdata:
  ak_redis:

Готовые файлы с комментариями по каждой переменной есть в наших разборах: Keycloak в docker compose и Authentik в docker compose. Оба сервера отдаются наружу через reverse proxy с TLS — обычно Traefik или nginx, порт наружу не открывайте напрямую.

Протоколы и интеграции: где кто сильнее

Здесь принципиальное отличие не в «поддерживает/не поддерживает», а в том, насколько зрело и предсказуемо работает каждый протокол.

SAML 2.0. Keycloak реализует SAML полнее и стабильнее — это исторически его основная ниша, там, где корпоративные заказчики (банки, госсектор, крупный enterprise-софт вроде Atlassian, SAP) требуют именно SAML с конкретными атрибутами и подписями. Authentik тоже умеет SAML как Service Provider и Identity Provider, но по опыту сообщества там чаще встречаются нюансы с нестандартными SP, которые приходится донастраивать через кастомные property mappings.

OIDC/OAuth2. Оба реализуют современно и без нареканий. Authentik здесь местами удобнее за счёт визуальных Property Mappings — можно на лету добавить claim в токен без перезапуска и без правки XML. Keycloak тоже это умеет через Client Scopes и Mappers, но UI менее интуитивен.

LDAP. Keycloak умеет как федерацию с внешним LDAP/AD (читать пользователей оттуда), так и — с ограничениями — работать в обратную сторону. Authentik может выступать LDAP-провайдером через отдельный outpost-контейнер, эмулируя LDAP-сервер для legacy-приложений, которые больше ничего не понимают. Это удобная фишка, если у вас завалялся Zabbix или Samba, умеющий только LDAP-аутентификацию.

Forward-auth / прокси-защита. Authentik изначально заточен под этот сценарий: outpost вешается перед приложением через Traefik или nginx как forward-auth middleware, и вы получаете SSO-защиту для сервисов, которые вообще не умеют OIDC — например, статичной админки без встроенной авторизации. У Keycloak похожая схема возможна через keycloak-gatekeeper/oauth2-proxy, но это уже сторонний компонент, а не часть экосистемы. Если у вас так реализована защита прокси, посмотрите наш разбор Traefik как reverse proxy для докера — оба IdP чаще всего ставят именно за Traefik.

2FA/MFA. У обоих есть TOTP из коробки, WebAuthn/passkeys, поддержка recovery-кодов. Authentik добавляет гибкие flows, где можно, например, требовать второй фактор только для конкретной группы пользователей или конкретного приложения — без написания кастомного кода, просто собирая цепочку шагов через UI.

UX администрирования: где меньше кликов и головной боли

Admin Console Keycloak — мощная, но перегруженная: чтобы создать нового клиента (приложение) с нужными redirect URI и mappers, нужно пройти 4-5 вкладок, и на первых порах легко забыть включить нужный флаг (например, Standard Flow Enabled для authorization code flow). Realm — как отдельное пространство имён — удобная концепция для мультитенантности (отдельный realm под каждого клиента SaaS), но сама по себе добавляет уровень вложенности, который приходится держать в голове.

Authentik построен вокруг concept of Flows — вы визуально собираете цепочку: identification stage → password stage → MFA stage → consent stage, и это же можно клонировать и модифицировать под конкретный сценарий (например, отдельный flow для password reset с email-верификацией). Для человека, который уже настраивал единичные интеграции руками, это ощущается быстрее — но требует привыкания к самой концепции flow, если вы никогда с ней не сталкивались.

Частые ошибки при эксплуатации у обоих продуктов однотипны — забытый KC_HOSTNAME/AUTHENTIK_HOST, неверный redirect URI, просроченный сертификат за прокси. Мы собрали конкретные случаи и их решения отдельно: частые ошибки Keycloak и частые ошибки Authentik.

Бэкап и восстановление: что теряете при сбое

Оба хранят всё состояние (пользователей, клиентов, realm/flows, секреты) в Postgres — значит, стратегия бэкапа сводится к регулярному pg_dump плюс копия .env/секретов, которые не лежат в БД.

Keycloak экспортирует конфигурацию realm в JSON командой:

/opt/keycloak/bin/kc.sh export --dir /tmp/kc-export --realm myrealm

Это удобно для переноса между окружениями (dev → prod), но требует остановки инстанса в отдельных версиях, если экспортируете «на горячую» через админку — проверяйте актуальное поведение в вашей версии перед тем как полагаться на этот способ как единственный.

Authentik бэкапится проще с точки зрения инструментария — там нет отдельного формата экспорта конфигурации, весь стейт идёт через дамп Postgres, но зато AUTHENTIK_SECRET_KEY обязательно нужно сохранить отдельно и неизменным: потеряете его — не расшифруете существующие сессии и некоторые секреты в БД.

Подробные пошаговые сценарии с cron-заданиями и восстановлением на чистом сервере — в отдельных материалах: бэкап и восстановление Keycloak и бэкап и восстановление Authentik.

Когда что выбирать: практические сценарии

Сведём в чёткие правила, а не абстрактное «зависит».

Берите Keycloak, если:

• нужен SAML для интеграции с корпоративным SaaS (Salesforce, SAP, банковские системы) — там это протокол по умолчанию;
• заказчик или аудит безопасности прямо требует Keycloak как «известный» и сертифицированный по SOC2/ISO продукт;
• у вас уже есть Java-инфраструктура и команда, которой привычен этот стек;
• планируется мультитенантность через отдельные realm для разных клиентов одного SaaS-продукта.

Берите Authentik, если:

• защищаете набор self-hosted сервисов (Nextcloud, Gitea, Grafana, Proxmox, внутренние дашборды) единым SSO, и часть из них вообще не умеет OIDC — тогда forward-auth outpost закрывает эти пробелы;
• сервер небольшой (1-2 ГБ RAM) и важна экономия ресурсов на старте;
• хочется гибко настраивать сценарии входа (условная MFA, разные flow для разных групп) без написания кастомных Java SPI;
• команда небольшая, и порог входа в UI важнее полноты enterprise-фич.

Смешанный случай. Если у вас уже стоит Keycloak «потому что так исторически сложилось» и он справляется — менять его на Authentik ради экономии 300-500 МБ RAM не имеет смысла: миграция realm с пользователями, ролями и client-секретами — это риск и время, которое дороже апгрейда VPS на один тариф выше. Для нового проекта с нуля выбор делайте по списку сценариев выше, а не по симпатиям.

Частые вопросы