Authentik, ZITADEL или Keycloak: какой self-hosted SSO выбрать?

У вас на VPS работают восемь Docker-контейнеров. Gitea, Nextcloud, Grafana, Vaultwarden, n8n, Portainer, страница статуса и одно внутреннее приложение, которое вы написали сами. У каждого свой вход. Каждое утро вы копируете пароли из менеджера паролей и уже начинаете задумываться, стоит ли единый вход своих эксплуатационных затрат.

Обычно стоит. Вопрос в том, какой провайдер идентификации запускать.

Keycloak — привычный вариант по умолчанию, но лучший выбор зависит от того, как выглядит ваш стек, сколькими пользователями вы управляете и что вы делаете: подключаете уже работающее ПО или встраиваете аутентификацию в собственные приложения.

В этом сравнении self-hosted SSO мы рассматриваем Authentik, ZITADEL, Keycloak и Authelia через призму решений, которые важны после развёртывания: поддержка протоколов, управление пользователями, рабочий процесс разработчика, требования к ресурсам и то, что происходит, когда провайдер идентификации падает.

Почему self-hosted SSO важен

Как только несколько приложений зависят от одних и тех же людей и групп, раздельные входы перестают быть удобными. Self-hosted провайдер идентификации даёт одно место для управления учётными записями, MFA, членством в группах и политиками доступа вместо того, чтобы настраивать эти механизмы отдельно в каждом приложении.

Обратная сторона не менее важна: IdP становится инфраструктурой, от которой зависят другие приложения. Когда он недоступен, новые входы и обновления токенов могут сбоить, поэтому резервные копии, аварийный доступ, обновления и доступность здесь значат больше, чем для обычного self-hosted приложения.

Кратко (TL;DR)

Выбирайте Authentik, если хотите лучший вариант по умолчанию

Для домашней лаборатории, стека внутренних инструментов или небольшой команды, подключающей существующие приложения через OIDC или SAML, Authentik — самый сильный вариант по умолчанию. Его административный интерфейс проще освоить, чем у Keycloak, он поддерживает несколько способов интеграции, а официальная конфигурация Docker Compose стартует с 2 ядер CPU и 2 ГБ RAM.

Выбирайте ZITADEL, если вы разрабатываете приложения

Выбирайте ZITADEL, когда аутентификация — часть продукта, который вы создаёте. Его модель организаций, API, мультиарендность, OIDC, SAML, passkeys, MFA и поддержка LDAP-провайдеров идентификации больше подходят командам SaaS и B2B-приложений, чем типичной домашней лаборатории.

Выбирайте Keycloak, если нужны корпоративные функции управления идентификацией

Выбирайте Keycloak, когда нужны более глубокая федерация с LDAP или Active Directory, несколько realm, детальные политики авторизации или среда, уже построенная вокруг Keycloak. Документация рекомендует лимит памяти 2 ГБ для небольших production-контейнеров Keycloak; VPS «всё в одном», на котором также работает PostgreSQL, потребует дополнительного запаса.

Альтернатива: выбирайте Authelia, если вам в основном нужна стена входа

Выбирайте Authelia, когда главная задача — защитить приложения на уровне обратного прокси, а не запускать полноценную платформу идентификации. Она может работать и как провайдер OpenID Connect, но аутентификация на обратном прокси остаётся её центром тяжести.

Что проверить перед выбором SSO-инструмента

Прежде чем сравнивать функции, сопоставьте каждый инструмент с приложениями, протоколами и источниками идентификации, которые вам уже нужно поддерживать.

Скольким приложениям нужен SSO?

Начинайте с приложений, а не с провайдера идентификации. Стек из шести приложений, которые уже поддерживают OIDC или SAML, — это другая задача, чем стек старых внутренних инструментов, которые ничего не знают ни об одном из протоколов. Первый случай указывает на полноценный IdP. Второму может понадобиться аутентификация на уровне обратного прокси.

Поддерживают ли ваши приложения OIDC или SAML?

OIDC — обычный выбор для современных веб-приложений. SAML по-прежнему важен в корпоративном ПО и старых интеграциях. LDAP имеет значение, когда приложение ожидает каталог, а не веб-поток SSO. Проверьте, что именно принимает каждое приложение, прежде чем выбирать IdP, который встанет посередине.

Вы управляете пользователями или встраиваете вход в приложение?

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

Нужны ли вам LDAP, Active Directory или продвинутые политики?

Authentik, ZITADEL и Keycloak в той или иной форме могут подключаться к источникам идентификации на базе LDAP, так что один только LDAP больше не решает исход сравнения. Keycloak становится интереснее, когда федерация каталогов сочетается с несколькими realm, детальными мапперами, требованиями к синхронизации или политиками авторизации на уровне ресурсов.

Authentik vs ZITADEL vs Keycloak vs Authelia

Четыре инструмента пересекаются в области SSO, но подходят к идентификации с разных сторон: интеграция приложений, идентификация продукта, корпоративный IAM и доступ через обратный прокси.

Authentik

Базовое развёртывание Authentik состоит из сервера, воркера и базы данных PostgreSQL. Redis больше не входит в стек: Authentik полностью убрал эту зависимость в релизе 2025.10. Текущая документация по Docker Compose требует хост как минимум с 2 ядрами CPU и 2 ГБ RAM.

Определяющая черта — административный интерфейс. Движок потоков Authentik, подключение приложений и групповые политики освоить проще, чем более широкую модель конфигурации Keycloak. Если вы когда-нибудь настраивали OIDC-приложение в Keycloak, а потом тратили время на поиски пропавших claims в токене, разница заметна быстро.

Он поддерживает SAML, OAuth2/OIDC, LDAP и RADIUS. Это правильный выбор по умолчанию для домашней лаборатории или небольшой инженерной команды со стеком self-hosted приложений.

ZITADEL

ZITADEL написан преимущественно на Go, распространяется под лицензией AGPL-3.0 и находится на линейке релизов v4.x. Развёртывание включает API на Go, интерфейс входа на Next.js и PostgreSQL, а текущие требования поддерживают PostgreSQL с 14 по 18. Официальная документация по Docker Compose требует хост как минимум с 2 ГБ RAM.

Определяющая черта — API. ZITADEL открывает полную поверхность идентификации через gRPC и REST и с самого начала построен на мультиарендной модели. Если вы создаёте SaaS-продукт и хотите, чтобы слой входа был программируемым, автоматизируемым и мультиарендным по умолчанию, ZITADEL ближе к тому, что вам нужно, чем альтернативы.

Он поддерживает OIDC, SAML, passkeys, MFA, LDAP-провайдеры идентификации и интерфейс SCIM v2, который сейчас помечен как Preview. Модель организаций и рабочий процесс, ориентированный на API, делают его более подходящим для продуктовых команд, чем для простой домашней лаборатории.

Keycloak

Keycloak — платформа управления идентификацией и доступом на Java, работающая на Quarkus. У него более широкая поверхность конфигурации, чем у остальных вариантов здесь, особенно когда в игру вступают Realms, Clients, Roles, федерация пользователей и Authorization Services.

Официальная документация по контейнерам рекомендует лимит памяти 2 ГБ для небольших production-развёртываний. Эта цифра относится к самому контейнеру Keycloak; если PostgreSQL делит тот же VPS, дайте хосту больше запаса.

Причина мириться с этой сложностью вполне конкретна. Keycloak умеет федерировать каталоги LDAP и Active Directory, записывать события пользователей и администраторов и применять детальную авторизацию с политиками RBAC, ABAC, на основе пользователя, на основе контекста и других типов. Если вам нужны такие механизмы, у дополнительной настройки есть смысл.

Authelia

Authelia — самая маленькая из четырёх: лицензия Apache 2.0, один бинарный файл на Go, сейчас на версии v4.39.x. Архитектура отличается от трёх остальных: Authelia стоит перед обратным прокси (nginx, Traefik, Caddy, HAProxy) и решает, можно ли пропустить запросы к бэкенду.

Authelia также включает провайдер OpenID Connect. Документация по-прежнему описывает реализацию OIDC как открытую бету, но провайдер сертифицирован OpenID по профилям Basic OP, Implicit OP, Hybrid OP, Form Post OP и Config OP. Набор функций OIDC у него уже, чем у Authentik или Keycloak в части управления идентификацией, поэтому Authelia по-прежнему логичнее всего использовать там, где главная задача — аутентификация на обратном прокси.

К Authelia мы вернёмся в отдельном разделе. Если коротко: центр тяжести Authelia — контроль доступа на обратном прокси, а не полноценное управление идентификацией.

Сравнение функций

Таблица ниже ограничивает сравнение различиями, которые влияют на развёртывание и повседневное администрирование.

Какой инструмент подходит какому стеку?

Лучший выбор меняется в зависимости от того, кто эксплуатирует IdP и как приложения с ним интегрируются.

Лучший вариант для домашней лаборатории

Authentik — выбор по умолчанию для домашней лаборатории, где большинство приложений уже поддерживают OIDC или SAML. Он даёт полноценный провайдер идентификации, не заставляя перенимать более широкую модель IAM Keycloak. Если большей части стека нужен экран входа на обратном прокси, а не нативный SSO, Authelia может оказаться более простым выбором.

Лучший вариант для стека небольшого бизнеса

Authentik подходит большинству небольших стеков внутренних приложений, особенно когда цель — единый слой идентификации для таких инструментов, как Grafana, Gitea, Nextcloud и Vaultwarden. Keycloak становится привлекательнее, когда в требования входят существующий каталог, несколько realm или более глубокие политики авторизации.

Лучший вариант для разработчиков и SaaS-продуктов

ZITADEL подходит лучше всего, когда аутентификация — часть продукта, который вы создаёте. Его модель организаций, мультиарендность, API и возможности автоматизации имеют больше смысла, когда пользователей и арендаторов нужно создавать из кода приложения, а не преимущественно через панель администратора.

ЧИТАТЬ

Лучшая self-hosted CIAM-платформа для создателей B2B SaaS

Лучший вариант для корпоративных команд и команд со строгими требованиями к соответствию

Keycloak имеет смысл, когда в списке требований — сложная федерация каталогов, несколько realm, детальные политики авторизации и команда, способная справиться с дополнительной сложностью IAM. Самостоятельный хостинг Keycloak сам по себе не делает среду соответствующей требованиям; резервные копии, доступность, журналирование, проверки доступа и контроль изменений остаются на вашей команде.

Лучший вариант для приложений без встроенного SSO

Authelia — самый очевидный выбор, когда аутентификация должна происходить до того, как запросы доходят до приложения. Она особенно хорошо работает с обратными прокси, защищающими старые внутренние инструменты, дашборды и сервисы, которые сами не поддерживают OIDC или SAML.

Самое сложное в self-hosted SSO

Как только SSO становится обязательным, ошибка в конфигурации или неудачное восстановление могут затронуть сразу несколько приложений.

Установка и настройка

Запустить контейнеры — только первый шаг. DNS, TLS, URI перенаправления, claims токенов, сопоставление групп, доставка почты и аварийный доступ — вот где развёртывание SSO начинает превращаться в инфраструктуру, а не в ещё одно Docker-приложение.

Ресурсы сервера

IdP — лишь часть бюджета ресурсов. PostgreSQL, обратные прокси, воркеры, хеширование паролей, логи и синхронизация каталогов могут конкурировать за CPU и память, когда делят один VPS.

Управление базой данных и резервными копиями

Authentik, ZITADEL и обычные production-развёртывания Keycloak зависят от базы данных. Делайте резервную копию этой базы за пределами сервера, документируйте порядок восстановления и тестируйте его. Успешно отработавшее задание резервного копирования — не то же самое, что рабочая процедура восстановления.

Риски блокировки и восстановления

Неверный URI перенаправления, истёкший секрет клиента, сломанное подключение к каталогу или слишком строгая политика могут заблокировать администраторов вместе со всеми остальными. Держите путь восстановления, который не зависит от того потока аутентификации, который вы пытаетесь починить.

Поддержание доступности IdP

Сбой IdP не обязательно сразу завершает все существующие сессии приложений. Текущие сессии могут продолжаться, пока не истекут их собственные токены или cookie, но новые входы и обновления токенов могут сбоить. Проверьте этот режим отказа, прежде чем делать SSO обязательным для всего стека.

Когда не стоит самостоятельно размещать SSO

Самостоятельный хостинг перестаёт быть выгодным, когда ваша команда не может восстанавливать и эксплуатировать слой идентификации с той надёжностью, которой требуют ваши приложения.

Когда управляемая идентификация безопаснее

За управляемую идентификацию стоит платить, когда стоимость эксплуатации IdP выше, чем контроль, который даёт самостоятельный хостинг. Такие сервисы, как Auth0, Clerk, WorkOS и Microsoft Entra ID, перекладывают на провайдера значительную часть забот о доступности платформы, установке исправлений и обслуживании инфраструктуры.

Конфигурация приложений, права и планирование восстановления по-прежнему на вас, но вы больше не отвечаете за то, чтобы сама платформа идентификации оставалась в строю.

Когда ваша команда не справится с простоем

Если во время сбоя никто в команде не сможет восстановить IdP, починить PostgreSQL, заменить истёкший секрет или диагностировать неработающее федеративное подключение, self-hosted идентификация может оказаться неверным эксплуатационным компромиссом.

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

Когда требования к соответствию слишком высоки

Self-hosted идентификацию можно использовать в регулируемых средах, но самостоятельный запуск ПО не создаёт автоматически тех механизмов контроля и доказательств, которых ожидает аудитор. Ваша команда по-прежнему отвечает за журналирование, проверки доступа, резервные копии, управление изменениями, доступность, реагирование на инциденты и всю документацию, которую требует применимый стандарт.

Self-hosted SSO — не символ статуса. Если ваша команда не может безопасно эксплуатировать слой идентификации, платить за управляемую идентификацию может быть более правильным инженерным решением.

Чем помогает Cloudzy

Cloudzy меняет слой развёртывания; он не избавляет от описанной выше работы по настройке идентификации и эксплуатации.

Проблема ручного развёртывания SSO

Ручное развёртывание SSO означает подготовку сервера, установку приложения и базы данных, настройку обратного прокси, DNS и TLS, и только потом — начало собственно настройки идентификации. Ничто из этого не заменяет последующую работу с OIDC, SAML, каталогом или политиками.

Развёртывание SSO в один клик на Cloudzy

У Cloudzy есть развёртывания в один клик для Authentik и Keycloak. Приложение Authentik в один клик есть в маркетплейсе Cloudzy. Приложение Keycloak в один клик тоже есть в маркетплейсе Cloudzy. ZITADEL сегодня в маркетплейсе нет, поэтому разворачивайте его через его конфигурацию Docker Compose на стандартном VPS. Установка в один клик запускает базовое приложение, а настройка идентификации, DNS, резервные копии, обновления, политики и проверка восстановления остаются под вашим контролем.

Когда стоит выделить под IdP отдельный VPS

Размещать IdP вместе с приложениями разумно для домашней лаборатории, где простой допустим. Для критичного для бизнеса стека вынос провайдера идентификации на отдельный сервер устраняет очевидную общую точку отказа: перезапуск, исчерпание ресурсов или компрометация сервера приложений больше не роняют вместе с ним слой идентификации.

Отдельный VPS — это ещё не высокая доступность, но он даёт IdP собственный бюджет ресурсов, собственный график обслуживания и собственную границу восстановления.

Рекомендации по размеру VPS

Рассчитывайте размер всего стека, а не только процесса IdP, особенно когда PostgreSQL и обратный прокси делят один VPS.

Требования Authentik к VPS

Официальная документация Authentik по Docker Compose требует хост как минимум с 2 ядрами CPU и 2 ГБ RAM. Это правильная отправная точка для небольшого развёртывания. Добавьте серверу запас, когда тот же хост делят PostgreSQL, дополнительные аутпосты, синхронизация каталогов или более интенсивный трафик входов.

Требования ZITADEL к VPS

Официальное развёртывание ZITADEL через Docker Compose требует для хоста как минимум 2 ГБ RAM. Рассчитывайте VPS «всё в одном» для ZITADEL, его интерфейса входа, PostgreSQL и обратного прокси вместе, а не рассматривайте Go-сервис изолированно.

Требования Keycloak к VPS

Документация Keycloak по контейнерам рекомендует лимит памяти 2 ГБ для небольших production-развёртываний Keycloak. Эта цифра относится к самому контейнеру Keycloak, а не ко всему VPS, на котором также работает PostgreSQL.

Если Keycloak и PostgreSQL делят один VPS, 4 ГБ системной RAM — разумная отправная точка. Считайте это практической рекомендацией для хоста, а не официальным минимумом Keycloak.

Требования Authelia к VPS

Authelia не публикует напрямую сопоставимого серверного минимума в 1 ГБ или 2 ГБ. Рассчитывайте хост для Authelia вместе с обратным прокси, бэкендом хранилища, каталогом пользователей и любыми другими сервисами на той же машине.

У Authelia обычно меньший след развёртывания, чем у полноценного IdP вместе с PostgreSQL, но реальные требования к VPS зависят от остального стека.

Пример настройки: Authentik с Vaultwarden

Vaultwarden добавил нативную поддержку SSO по OpenID Connect в версии 1.35.0 в декабре 2025 года. Authentik — полезный пример, потому что интеграция показывает те элементы OIDC, с которыми вы столкнётесь и в других приложениях: URI перенаправления, учётные данные клиента, scope, URL издателя и аварийный доступ.

Базовая настройка Authentik

В Authentik:

1. Создайте пользовательское сопоставление email-scope для Vaultwarden. Vaultwarden требует, чтобы scope email возвращал либо email_verified: true, либо вообще не содержал значения email_verified, тогда как стандартный email-scope Authentik сейчас возвращает false.
2. Создайте пару приложение и провайдер OAuth2/OpenID Connect.
3. Добавьте https://vault.example.com/identity/connect/oidc-signin как строгий URI перенаправления типа Authorization.
4. Выберите любой доступный ключ подписи.
5. Запишите Client ID, Client Secret и slug приложения.
6. Установите срок действия токена доступа больше пяти минут.
7. Добавьте сопоставление offline_access из Authentik к выбранным scope.
8. Замените стандартное сопоставление email на пользовательское сопоставление подтверждённого email из шага 1.

Базовая настройка OIDC в Vaultwarden

Используйте:

DOMAIN=https://vault.example.com
SSO_ENABLED=true
SSO_AUTHORITY=https://idp.example.com/application/o/vaultwarden/
SSO_CLIENT_ID=vaultwarden
SSO_CLIENT_SECRET=<paste-secret-from-authentik>
SSO_SCOPES=email profile offline_access
SSO_ALLOW_UNKNOWN_EMAIL_VERIFICATION=false
SSO_CLIENT_CACHE_EXPIRATION=0
SSO_ONLY=false
SSO_SIGNUPS_MATCH_EMAIL=true

Замените примерные домены, slug приложения, идентификатор клиента и секрет клиента значениями из вашего развёртывания, затем перезапустите Vaultwarden.

ЧИТАТЬ

Self-host менеджера паролей Bitwarden: полное руководство

Что протестировать, прежде чем делать SSO обязательным

Оставьте SSO_ONLY в значении false, пока тестируете вход, выход, обновление токенов, сопоставление учётных записей и восстановление. Проверьте также, что происходит, когда Authentik временно недоступен.

Когда и SSO, и восстановление работают как ожидается, можно решить, есть ли смысл требовать SSO для каждого входа в вашем развёртывании.

Те же принципы OIDC применимы к другим self-hosted приложениям, но URI перенаправления, scope, claims и лицензии различаются. Сверяйтесь с документацией по SSO каждого приложения, а не копируйте конфигурацию Vaultwarden напрямую.

Когда Authelia лучше полноценного IdP

Authelia становится привлекательнее, когда приложению вообще не нужно понимать провайдера идентификации.

Аутентификация на обратном прокси

Authelia в первую очередь создана для защиты приложений на уровне обратного прокси. Вы задаёте правила контроля доступа, а Authelia решает, должен ли запрос дойти до бэкенда, ещё до того, как аутентификацией займётся само приложение.

Защита приложений без OIDC

Это полезно для старых внутренних инструментов, дашбордов и сервисов, которые не поддерживают OIDC или SAML. Вместо того чтобы дорабатывать каждое приложение, вы можете поставить аутентификацию перед ним, на обратном прокси.

Authelia может работать и как провайдер OIDC, но аутентификация на обратном прокси остаётся её главной сильной стороной.

Использование Authelia вместе с Authentik

Вы можете использовать Authentik для приложений с поддержкой OIDC или SAML и Authelia для приложений, которым нужна аутентификация на обратном прокси.

Оба вам не обязательно нужны. Authentik тоже поддерживает защиту приложений через прокси, так что Authelia рядом с ним имеет смысл только тогда, когда её рабочий процесс на обратном прокси решает конкретную часть вашего стека чище.

Часто задаваемые вопросы

Authentik лучше Keycloak?

Для большинства домашних лабораторий и небольших стеков self-hosted приложений Authentik проще в освоении. Его административный процесс сосредоточен на приложениях, провайдерах, группах и политиках и не вываливает сразу столько сложности IAM.

Keycloak логичнее, когда вам конкретно нужны его более глубокая федерация, модель realm или Authorization Services. Authentik — более сильный вариант по умолчанию для простого self-hosted SSO; Keycloak подходит средам, которым нужны эти дополнительные механизмы контроля.

ZITADEL лучше Keycloak?

ZITADEL подходит лучше, когда вы создаёте продукт и хотите идентификацию, управляемую через API, организации и мультиарендность. Keycloak подходит лучше, когда вам нужны его более глубокая модель авторизации, обширные механизмы федерации или среда, уже построенная вокруг Keycloak.

В чём разница между Authentik и Authelia?

Authentik — полноценный провайдер идентификации, построенный вокруг пользователей, групп, приложений, провайдеров, потоков и политик. Приложения могут интегрироваться с ним напрямую по таким протоколам, как OIDC и SAML.

Authelia сосредоточена на аутентификации и контроле доступа на обратном прокси. Она тоже включает провайдер OIDC, но защита на обратном прокси остаётся её основным сценарием.

Выбирайте Authentik, когда приложения интегрируются с IdP напрямую. Выбирайте Authelia, когда аутентификация в основном должна происходить до того, как трафик дойдёт до приложения.

Можно ли запустить Authentik на VPS с 1 ГБ?

Не как поддерживаемую отправную точку. Текущая документация Authentik по Docker Compose требует как минимум 2 ядра CPU и 2 ГБ RAM. Текущее базовое развёртывание использует сервер Authentik, воркер и PostgreSQL; Redis был полностью удалён в Authentik 2025.10.

Берите 2 ГБ как минимальную отправную точку для небольшой установки и добавляйте запас, когда машину делят другие сервисы.

Поддерживает ли Vaultwarden SSO по OIDC?

Да. Vaultwarden добавил поддержку SSO по OpenID Connect в версии 1.35.0 в декабре 2025 года. Ему нужен внешний провайдер OIDC, например Authentik, Keycloak или ZITADEL.

Точная конфигурация зависит от провайдера. Для текущих релизов Authentik задокументированная интеграция включает пользовательское сопоставление scope подтверждённого email, offline_access, учётные данные клиента и URL издателя приложения Authentik.

Стоит ли размещать IdP на том же VPS, что и приложения?

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

Само по себе это не создаёт высокой доступности, но перезапуск сервера приложений, проблема с ресурсами или компрометация больше не роняют IdP автоматически вместе с ним.

Какой self-hosted SSO проще всего в использовании?

Authentik — самая простая отправная точка для большинства тех, кто подключает существующие self-hosted приложения. Его административный интерфейс делает приложения, провайдеров, группы и политики понятнее, чем более широкая модель realm и авторизации Keycloak.

Authelia может быть проще, когда вам нужна только аутентификация на обратном прокси. ZITADEL логичнее, когда идентификацию настраивает разработчик, работающий преимущественно через API.