Keycloak чи Authentik – типове питання, коли в homelab накопичуються Proxmox, Grafana, Immich, Nextcloud, VPN, внутрішні панелі й окремі адмінки. Обидва продукти закривають self-hosted SSO, але підходять до цього по-різному. Тут логічніше вибирати не за списком функцій, а за тим, скільки сервісів треба звести під один login, як часто доведеться допилювати інтеграції і хто потім це буде обслуговувати.
Коротка відповідь така: для домашнього homelab з невеликим набором сервісів частіше краще заходить Authentik. Для складнішої схеми з чіткими ролями, federated login, кількома realm-подібними контурами і вимогою до зрілої IAM-моделі – Keycloak. Якщо SSO потрібен насамперед для reverse proxy і кількох вебсервісів, перевантажувати стек Keycloak немає сенсу.
Нижче – не загальний огляд, а порівняння по тих місцях, де зазвичай і ламається вибір: модель доступу, інтеграції, операційна ціна, поведінка за reverse proxy і межа, після якої простий сценарій раптом стає IAM-проєктом.
Спершу вибирають не продукт, а сценарій
Якщо відкинути маркетингові описи, різниця проста. Keycloak ближчий до класичної IAM-системи. Authentik ближчий до практичного SSO-хабу для self-hosted сервісів і доступу через proxy outpost. Саме тому keycloak чи authentik треба порівнювати від потоку входу, а не від чекліста можливостей.
У домашній інфраструктурі найчастіше трапляються два сценарії. Перший – застосунки вже вміють OIDC або SAML, і потрібен нормальний identity provider. Другий – половина сервісів узагалі не має вбудованої федерації, тому доступ доводиться ставити перед ними через reverse proxy. На цьому місці Authentik часто скорочує кількість клею між сервісами.
Keycloak сильніший там, де модель користувачів, груп і клієнтів швидко розростається. Окремі ролі для адмінок, сервісні акаунти, тонке керування claims, зовнішні identity source – усе це вписується в його логіку природніше. Але для дванадцяти контейнерів і трьох людей у домі така архітектура легко стає важчою, ніж сама проблема.
Де Authentik дає менше тертя
Authentik зазвичай зручніший у homelab, коли треба швидко підв’язати різношерсті вебсервіси під один login. Його сильна сторона – не лише роль IdP, а й сценарії доступу через outpost та інтеграція з reverse proxy. Для self-hosted інфраструктури це часто корисніше за формально багатшу IAM-модель.
На практиці проблема рідко в тому, щоб підняти сам сервер автентифікації. Проблема в іншому – старий контейнер не вміє OIDC, домашня адмінка має дивну схему callback URL, ще один сервіс працює тільки за заголовками від proxy. У такій суміші Authentik часто проходить коротшим маршрутом.
Ще один момент – візуальна модель flows. Для невеликих інсталяцій це прискорює розуміння, де саме виконується MFA, де перевіряється група, а де йде редірект. Ціна цього підходу теж існує: коли flows стає забагато, логіка роз’їжджається по UI, і шукати причину відмови вже складніше, ніж у більш прямолінійній моделі.
Офіційний сайт проєкту – Authentik.
Коли Keycloak виграє без дискусії
Keycloak доречніший, коли self-hosted SSO перестає бути просто входом у кілька панелей і перетворюється на центр доступу для різних контурів. Якщо потрібні складні ролі, жорсткіші політики доступу, зовнішні провайдери і більш передбачувана IAM-логіка, Keycloak зазвичай дає кращий фундамент.
Його модель добре лягає на сценарії, де є окремі клієнти, різні політики для сервісів, виділені області доступу й потреба жити довго без ручних обхідних шляхів. Там, де Authentik може закрити задачу через proxy і flow, Keycloak частіше штовхає до явної інтеграції на рівні протоколу. Це довше на старті, зате чистіше через рік.
Нетривіальний момент: у homelab Keycloak часто вибирають із запасом, але цей запас рідко конвертується в користь. Якщо немає потреби в серйозній IAM-структурі, доведеться тягнути складніший operational footprint лише тому, що продукт вважають enterprise-grade. Для двох dozen сервісів це сумнівний обмін.
Офіційний сайт – Keycloak.
Keycloak чи Authentik за ключовими критеріями
Нижче зведено те, що реально впливає на вибір у домашньому середовищі: складність старту, зручність інтеграцій, поведінка з proxy і межа зростання. Саме на цих пунктах питання keycloak чи authentik перестає бути теоретичним.
| Критерій | Authentik | Keycloak |
|---|---|---|
| Старт для homelab | Зазвичай швидший, особливо коли багато сервісів без нативного OIDC | Часто потребує чіткішого плану клієнтів, ролей і redirect flow |
| Робота через reverse proxy | Сильний сценарій через outpost і proxy-підхід | Можливо, але не це його головна сила |
| Чистий OIDC/SAML | Достатньо для більшості self-hosted кейсів | Сильний і зрілий варіант для складніших схем |
| Модель доступу | Простіше для невеликих команд і домашніх користувачів | Краще масштабується в IAM-сценарій |
| Операційна складність | Нижча на старті, але flow-логіка може заплутати з часом | Вища на старті, зате структура пряміша для великих схем |
| Коли починає дратувати | Коли багато нестандартних flows і винятків | Коли задача проста, а система надто важка для неї |
Типовий homelab-сценарій: що ставити під Grafana, Proxmox, Nextcloud і внутрішні адмінки
Для типового домашнього стеку з кількох вебсервісів, де частина має OIDC, а частина ні, частіше варто брати Authentik. Він краще підходить як центральна точка входу перед панелями, які живуть за reverse proxy. Keycloak у такій схемі має сенс, якщо потрібна дисципліна IAM, а не просто login once.
Grafana, Nextcloud, інші сучасні сервіси зазвичай нормально працюють напряму через OIDC. Проблеми починаються на внутрішніх панелях, адмінках контейнерів, старих інтерфейсах NAS або самописних сервісах. Якщо їх треба швидко накрити єдиною автентифікацією, Authentik закриває це природніше.
З Proxmox сценарій тонший. У такому середовищі краще не зводити все до одного зовнішнього входу без локального break-glass акаунта. Будь-який SSO у homelab повинен мати аварійний обхід, інакше збій reverse proxy або помилка в flow відріже доступ до всієї інфраструктури разом.
Як виглядає розгортання без зайвого болю
Для домашнього сценарію розгортання краще починати з одного домену для SSO, одного reverse proxy і двох сервісів для перевірки – одного з нативним OIDC, другого без нього. Така схема швидко показує, чи справді потрібен Keycloak, чи вистачить Authentik без подальшого ускладнення.
- Виділити окремий hostname для IdP, наприклад sso.example.net.
- Поставити систему за reverse proxy з коректними forwarded headers і TLS.
- Увімкнути локальний адміністративний доступ, який не залежить від зовнішньої автентифікації.
- Підключити сервіс з нативним OIDC – наприклад Grafana або інший вебзастосунок зі стандартним callback flow.
- Підключити один сервіс через proxy-підхід, якщо він не вміє OIDC.
- Після перевірки вже переносити інші адмінки та панелі.
Найгірший шлях – одразу поставити SSO перед усім, включно з reverse proxy, панеллю хоста і DNS-адмінкою. Якщо помилитися з cookie domain, redirect URI або trust headers, відкат робиться довше, ніж саме розгортання.
Де зазвичай все ламається
Проблеми в self-hosted SSO майже ніколи не зводяться до самого login form. Частіше ламаються redirect URI, time skew, cookie policy, заголовки від reverse proxy і некоректна схема external URL. У спорі keycloak чи authentik ці помилки однакові за природою, але проявляються по-різному.
За подвійним proxy або через Cloudflare-подібний фронт часто губиться правильна схема запиту. Сервіс думає, що працює по HTTP, хоча зовні доступний по HTTPS. Результат банальний: циклічний redirect, поламаний callback або cookie, яка не повертається після входу.
Окрема пастка – MFA на все підряд. Для адмінок це виправдано. Для технічних сервісів із короткими сесіями або інтеграціями через embedded browser воно швидко створює тертя. У домашньому стеку краще розділяти людський вхід і сервісний доступ, а не тягнути одну політику на все.
Ще одне практичне спостереження: що більше сервісів ховаються за proxy-auth, то важче потім мігрувати на нативний OIDC. Тому proxy-вхід добре працює як прискорювач старту, але не завжди як фінальна архітектура.
Як перевірити, що SSO працює коректно
Після запуску треба перевіряти не лише сам вхід, а всю сесійну поведінку: редірект, logout, оновлення токена, роботу з групами і відновлення після збою proxy. Якщо цього не зробити одразу, помилки вилізуть вже після переносу критичних адмінок.
- Увійти в сервіс напряму через SSO hostname і через звичну зовнішню адресу.
- Перевірити callback після повторного login у новій приватній сесії браузера.
- Переконатися, що logout завершує сесію і в застосунку, і в самому IdP.
- Перевірити доступ користувача без потрібної групи або ролі.
- Відкрити сервіс з іншого браузера або з мобільного клієнта.
- Тимчасово вимкнути proxy-маршрут і перевірити, чи лишився аварійний шлях входу.
Усе це нудно. Але саме тут стає видно, чи не побудована вся схема на одному крихкому cookie або неправильному external hostname.
Що обрати саме для домашнього homelab
Якщо потрібен практичний вибір, а не абстрактно найсильніший продукт, відповідь зазвичай проста. Для більшості домашніх інсталяцій keycloak чи authentik вирішується на користь Authentik, коли треба швидко і без зайвої IAM-архітектури зібрати SSO для self-hosted сервісів.
Keycloak краще брати тоді, коли вже видно майбутню складність: окремі контури доступу, багато клієнтів, жорстка рольова модель, інтеграція з зовнішніми identity provider, вимога до більш формального керування доступом. Якщо цього немає, Keycloak часто виявляється системою, яку доведеться обслуговувати заради самої системи.
У homelab гарне рішення не те, яке вміє більше, а те, яке не ламає доступ до інфраструктури в неділю ввечері. Іноді цього критерію вже достатньо.