У вас на 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 — контроль доступу на зворотному проксі, а не повноцінне керування ідентифікацією.
Порівняння функцій
Таблиця нижче обмежує порівняння відмінностями, які впливають на розгортання та повсякденне адміністрування.
| Функція | Authentik | ZITADEL | Keycloak | Authelia |
|---|---|---|---|---|
| Підтримувані протоколи | OAuth2/OIDC, SAML, LDAP, RADIUS, проксі-автентифікація | OAuth2/OIDC, SAML, LDAP-провайдер ідентифікації, SCIM v2 (Preview) | OAuth2/OIDC, SAML, федерація LDAP і Active Directory | Провайдер OIDC плюс автентифікація на зворотному проксі |
| Керування користувачами та групами | Користувачі, групи, політики, потоки, прив'язки застосунків | Користувачі, організації, проєкти, ролі, гранти | Користувачі, групи, realm, ролі клієнта, ролі realm, федерація | Легке керування користувачами, зазвичай на основі файлів або LDAP |
| Досвід розробника | API є, але головна сила — адміністративний інтерфейс | API-first, сильна модель організацій і мультиорендності | Зрілі REST API з більшою моделлю IAM, яку потрібно вивчити | Здебільшого керується конфігурацією |
| Корпоративні функції | Політики, федерація, аутпости, контроль доступу до застосунків | Організації, проєкти, passkeys, федерація, SCIM v2 (Preview) | Глибока федерація, кілька realm, події, Authorization Services | Правила контролю доступу та тісна інтеграція зі зворотним проксі |
| Простота налаштування | Простіша відправна точка для більшості стеків self-hosted застосунків | Найкращий вибір, коли команда мислить категоріями API та ідентифікації продукту | Більше понять і налаштувань, але глибший контроль | Найпростіше, коли задача — здебільшого автентифікація на зворотному проксі |
| Рекомендації щодо ресурсів | Офіційний мінімум для Compose: 2 ядра CPU і 2 ГБ RAM | Офіційний мінімум хоста для Compose: 2 ГБ RAM | Рекомендована пам'ять контейнера 2 ГБ для невеликих production-розгортань | Безпосередньо порівнянного офіційного мінімуму RAM немає |
Який інструмент пасує якому стеку?
Найкращий вибір змінюється залежно від того, хто експлуатує IdP і як застосунки з ним інтегруються.
Найкращий варіант для домашньої лабораторії
Authentik — вибір за замовчуванням для домашньої лабораторії, де більшість застосунків уже підтримують OIDC або SAML. Він дає повноцінний провайдер ідентифікації, не змушуючи переймати ширшу модель IAM Keycloak. Якщо більшій частині стека потрібен екран входу на зворотному проксі, а не нативний SSO, Authelia може виявитися простішим вибором.
Найкращий варіант для стека невеликого бізнесу
Authentik пасує більшості невеликих стеків внутрішніх застосунків, особливо коли мета — єдиний шар ідентифікації для таких інструментів, як Grafana, Gitea, Nextcloud і Vaultwarden. Keycloak стає привабливішим, коли до вимог входять наявний каталог, кілька realm або глибші політики авторизації.
Найкращий варіант для розробників і SaaS-продуктів
ZITADEL пасує найкраще, коли автентифікація — частина продукту, який ви створюєте. Його модель організацій, мультиорендність, API та можливості автоматизації мають більше сенсу, коли користувачів і орендарів потрібно створювати з коду застосунку, а не переважно через панель адміністратора.
Найкращий варіант для корпоративних команд і команд із суворими вимогами до відповідності
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, резервні копії, оновлення, політики та перевірка відновлення лишаються під вашим контролем.
Розробляйте на Linux VPS з root-доступом, NVMe та потужністю AMD EPYC.
Переглянути тарифи LinuxКоли варто виділити під 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:
- Створіть користувацьке зіставлення email-scope для Vaultwarden. Vaultwarden вимагає, щоб scope email повертав або email_verified: true, або взагалі не містив значення email_verified, тоді як стандартний email-scope Authentik наразі повертає false.
- Створіть пару застосунок і провайдер OAuth2/OpenID Connect.
- Додайте https://vault.example.com/identity/connect/oidc-signin як строгий URI перенаправлення типу Authorization.
- Виберіть будь-який доступний ключ підпису.
- Запишіть Client ID, Client Secret і slug застосунку.
- Встановіть термін дії токена доступу понад п'ять хвилин.
- Додайте зіставлення offline_access з Authentik до вибраних scope.
- Замініть стандартне зіставлення 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.
Що протестувати, перш ніж робити 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.
Обговорення
Коментарі
Увійдіть, щоб долучитися до обговорення.