Authentik vs ZITADEL vs Keycloak: które self-hosted SSO wybrać?

Masz osiem kontenerów Docker działających na VPS. Gitea, Nextcloud, Grafana, Vaultwarden, n8n, Portainer, strona statusu i jedna wewnętrzna aplikacja, którą napisałeś sam. Każdy ma własny login. Co rano kopiujesz hasła z menedżera haseł i zaczynasz się zastanawiać, czy pojedyncze logowanie jest warte kosztów operacyjnych.

Zwykle jest. Pytanie brzmi, którego dostawcę tożsamości uruchomić.

Keycloak to dobrze znany domyślny wybór, ale lepsze dopasowanie zależy od tego, jak wygląda twój stos, iloma użytkownikami zarządzasz i czy integrujesz oprogramowanie, które już działa, czy wbudowujesz uwierzytelnianie we własne aplikacje.

To porównanie self-hosted SSO analizuje Authentik, ZITADEL, Keycloak i Authelia przez pryzmat decyzji, które liczą się po wdrożeniu: obsługa protokołów, zarządzanie użytkownikami, przepływ pracy dewelopera, wymagania sprzętowe i to, co się dzieje, gdy dostawca tożsamości pada.

Dlaczego self-hosted SSO ma znaczenie

Gdy kilka aplikacji zależy od tych samych osób i grup, osobne logowania przestają być wygodne. Self-hosted dostawca tożsamości daje jedno miejsce do zarządzania kontami, MFA, członkostwem w grupach i politykami dostępu, zamiast konfigurowania tych mechanizmów osobno w każdej aplikacji.

Druga strona medalu jest równie ważna: IdP staje się infrastrukturą, od której zależą inne aplikacje. Nowe logowania i odświeżenia tokenów mogą się nie udać, gdy jest niedostępny, więc kopie zapasowe, dostęp awaryjny, aktualizacje i dostępność liczą się tu bardziej niż w zwykłej aplikacji self-hosted.

TL;DR

Wybierz Authentik, jeśli chcesz najlepszej opcji domyślnej

Dla homelabu, stosu wewnętrznych narzędzi lub małego zespołu podłączającego istniejące aplikacje przez OIDC lub SAML Authentik jest najmocniejszym domyślnym wyborem. Jego przepływ administracyjny jest łatwiejszy do opanowania niż w Keycloak, obsługuje kilka metod integracji, a oficjalna konfiguracja Docker Compose startuje od 2 rdzeni CPU i 2 GB RAM.

Wybierz ZITADEL, jeśli budujesz aplikacje

Wybierz ZITADEL, gdy uwierzytelnianie jest częścią produktu, który budujesz. Jego model organizacji, API, wielodostępność, OIDC, SAML, klucze passkey, MFA i obsługa dostawców tożsamości LDAP mają więcej sensu dla zespołów aplikacji SaaS i B2B niż dla typowego homelabu.

Wybierz Keycloak, jeśli potrzebujesz korporacyjnych funkcji tożsamości

Wybierz Keycloak, gdy potrzebujesz głębszej federacji z LDAP lub Active Directory, wielu realmów, szczegółowych polityk autoryzacji albo środowiska już zbudowanego wokół Keycloak. Dokumentacja zaleca limit pamięci 2 GB dla mniejszych, gotowych na produkcję kontenerów Keycloak; VPS typu wszystko w jednym, na którym działa też PostgreSQL, potrzebuje dodatkowego zapasu.

Alternatywa: wybierz Authelia, jeśli potrzebujesz głównie bramki logowania

Wybierz Authelia, gdy twoim głównym problemem jest ochrona aplikacji na warstwie reverse proxy, a nie prowadzenie pełnej platformy tożsamości. Może też działać jako dostawca OpenID Connect, ale uwierzytelnianie na reverse proxy pozostaje jego głównym obszarem.

Co sprawdzić przed wyborem narzędzia SSO

Zanim porównasz funkcje, zestaw każde narzędzie z aplikacjami, protokołami i źródłami tożsamości, które już musisz obsługiwać.

Ile aplikacji potrzebuje SSO?

Zacznij od aplikacji, nie od dostawcy tożsamości. Stos sześciu aplikacji, które już obsługują OIDC lub SAML, to inny problem niż stos starych wewnętrznych narzędzi, które nie znają żadnego z tych protokołów. Pierwszy przypadek wskazuje na pełny IdP. Drugi może wymagać uwierzytelniania na warstwie reverse proxy.

Czy twoje aplikacje obsługują OIDC lub SAML?

OIDC to typowy wybór dla nowoczesnych aplikacji webowych. SAML wciąż liczy się w oprogramowaniu korporacyjnym i starszych integracjach. LDAP ma znaczenie, gdy aplikacja oczekuje katalogu, a nie webowego przepływu SSO. Sprawdź, co każda aplikacja faktycznie akceptuje, zanim wybierzesz IdP, który stanie pośrodku.

Zarządzasz użytkownikami czy wbudowujesz logowanie w aplikację?

Jeśli większość pracy będzie się odbywać w interfejsie administracyjnym podczas podłączania istniejących aplikacji, Authentik jest naturalnym punktem startu. Jeśli uwierzytelnianie jest częścią produktu, który budujesz, i zamierzasz tworzyć organizacje, użytkowników i uprawnienia z poziomu kodu, ZITADEL jest znacznie bliżej tego przepływu pracy.

Czy potrzebujesz LDAP, Active Directory lub zaawansowanych polityk?

Authentik, ZITADEL i Keycloak mogą w jakiejś formie łączyć się ze źródłami tożsamości opartymi na LDAP, więc sam LDAP nie rozstrzyga już porównania. Keycloak staje się ciekawszy, gdy federacja katalogów łączy się z wieloma realmami, szczegółowymi mapperami, wymaganiami synchronizacji lub politykami autoryzacji na poziomie zasobów.

Authentik vs ZITADEL vs Keycloak vs Authelia

Cztery narzędzia pokrywają się w zakresie SSO, ale podchodzą do tożsamości z różnych stron: integracja aplikacji, tożsamość produktu, korporacyjny IAM i dostęp przez reverse proxy.

Authentik

Authentik uruchamia swoje podstawowe wdrożenie jako serwer, worker i bazę danych PostgreSQL. Redis nie jest już częścią stosu: Authentik całkowicie usunął tę zależność w wydaniu 2025.10. Aktualna dokumentacja Docker Compose wymaga hosta z co najmniej 2 rdzeniami CPU i 2 GB RAM.

Cechą charakterystyczną jest interfejs administracyjny. Silnik przepływów Authentik, provisioning aplikacji i polityki grupowe są łatwiejsze do opanowania niż szerszy model konfiguracji Keycloak. Jeśli kiedykolwiek skonfigurowałeś aplikację OIDC w Keycloak, a potem spędziłeś czas na dochodzeniu, dlaczego brakuje claimów w tokenie, różnica jest szybko zauważalna.

Obsługuje SAML, OAuth2/OIDC, LDAP i RADIUS. To właściwy domyślny wybór dla homelabu lub małego zespołu inżynierskiego prowadzącego stos aplikacji self-hosted.

ZITADEL

ZITADEL jest napisany głównie w Go, na licencji AGPL-3.0, i znajduje się w linii wydań v4.x. Wdrożenie obejmuje API w Go, interfejs logowania w Next.js i PostgreSQL, a aktualne wymagania obsługują PostgreSQL od 14 do 18. Oficjalna dokumentacja Docker Compose wymaga hosta z co najmniej 2 GB RAM.

Cechą charakterystyczną jest API. ZITADEL udostępnia pełną powierzchnię tożsamości przez gRPC i REST i od początku jest zbudowany na modelu wielodostępnym. Jeśli budujesz produkt SaaS i chcesz, aby warstwa logowania była programowalna, automatyzowalna i domyślnie wielodostępna, ZITADEL jest bliżej tego, czego szukasz, niż alternatywy.

Obsługuje OIDC, SAML, klucze passkey, MFA, dostawców tożsamości LDAP oraz interfejs SCIM v2, obecnie oznaczony jako Preview. Jego model organizacji i przepływ pracy API-first czynią go lepszym wyborem dla zespołów produktowych niż dla prostego homelabu.

Keycloak

Keycloak to platforma zarządzania tożsamością i dostępem w Javie, działająca na Quarkus. Ma większą powierzchnię konfiguracji niż pozostałe opcje tutaj, zwłaszcza gdy do gry wchodzą Realms, Clients, Roles, federacja użytkowników i Authorization Services.

Oficjalna dokumentacja kontenerów zaleca limit pamięci 2 GB dla mniejszych, gotowych na produkcję wdrożeń. Ta liczba dotyczy samego kontenera Keycloak; jeśli PostgreSQL dzieli ten sam VPS, daj hostowi więcej zapasu.

Powód, by zaakceptować tę złożoność, jest konkretny. Keycloak potrafi federować katalogi LDAP i Active Directory, rejestrować zdarzenia użytkowników i administratorów oraz egzekwować szczegółową autoryzację z politykami RBAC, ABAC, opartymi na użytkowniku, opartymi na kontekście i innymi. Jeśli potrzebujesz tych mechanizmów, dodatkowa konfiguracja ma sens.

Authelia

Authelia jest najmniejsza z całej czwórki: licencja Apache 2.0, pojedynczy plik binarny w Go, obecnie w wersji v4.39.x. Architektura różni się od pozostałych trzech: Authelia stoi przed reverse proxy (nginx, Traefik, Caddy, HAProxy) i decyduje, czy żądania mogą dotrzeć do backendu.

Authelia zawiera też dostawcę OpenID Connect. Dokumentacja wciąż opisuje implementację OIDC jako otwartą betę, ale dostawca ma certyfikat OpenID dla profili Basic OP, Implicit OP, Hybrid OP, Form Post OP i Config OP. Jego zestaw funkcji OIDC jest węższy niż to, co Authentik czy Keycloak oferują w zarządzaniu tożsamością, i dlatego Authelia nadal ma najwięcej sensu, gdy głównym zadaniem jest uwierzytelnianie na reverse proxy.

Do Authelia wrócimy w osobnej sekcji. W skrócie: głównym obszarem Authelia jest kontrola dostępu na reverse proxy, a nie pełne zarządzanie tożsamością.

Porównanie funkcji

Poniższa tabela ogranicza porównanie do różnic, które wpływają na wdrożenie i codzienną administrację.

Które narzędzie pasuje do którego stosu?

Najlepsze dopasowanie zmienia się w zależności od tego, kto obsługuje IdP i jak aplikacje się z nim integrują.

Najlepsza opcja dla homelabu

Authentik jest domyślnym wyborem dla homelabu, w którym większość aplikacji już obsługuje OIDC lub SAML. Daje pełnego dostawcę tożsamości bez konieczności przyjmowania szerszego modelu IAM Keycloak. Jeśli większość stosu potrzebuje ekranu logowania na reverse proxy zamiast natywnego SSO, Authelia może być prostszym wyborem.

Najlepsza opcja dla stosu małej firmy

Authentik pasuje do większości małych stosów aplikacji wewnętrznych, zwłaszcza gdy celem jest jedna warstwa tożsamości dla narzędzi takich jak Grafana, Gitea, Nextcloud i Vaultwarden. Keycloak staje się atrakcyjniejszy, gdy istniejący katalog, wiele realmów lub głębsze polityki autoryzacji są częścią wymagań.

Najlepsza opcja dla deweloperów i produktów SaaS

ZITADEL pasuje najlepiej, gdy uwierzytelnianie jest częścią produktu, który budujesz. Jego model organizacji, wielodostępność, API i możliwości automatyzacji mają więcej sensu, gdy użytkowników i tenantów trzeba tworzyć z kodu aplikacji, a nie głównie przez panel administracyjny.

CZYTAJ

Najlepszy samodzielnie hostowany CIAM dla twórców SaaS B2B

Najlepsza opcja dla zespołów korporacyjnych lub z dużymi wymaganiami zgodności

Keycloak ma sens, gdy lista wymagań obejmuje złożoną federację katalogów, wiele realmów, szczegółowe polityki autoryzacji i zespół, który potrafi obsłużyć dodatkową złożoność IAM. Samodzielne hostowanie Keycloak samo w sobie nie czyni środowiska zgodnym z regulacjami; kopie zapasowe, dostępność, logowanie zdarzeń, przeglądy dostępu i kontrola zmian nadal należą do twojego zespołu.

Najlepsza opcja dla aplikacji bez natywnego SSO

Authelia jest najbardziej oczywistym wyborem, gdy uwierzytelnianie musi nastąpić, zanim żądania dotrą do aplikacji. Szczególnie dobrze działa z reverse proxy chroniącymi starsze wewnętrzne narzędzia, dashboardy i usługi, które same nie obsługują OIDC ani SAML.

Trudna część samodzielnego hostowania SSO

Gdy SSO staje się obowiązkowe, błąd konfiguracji lub nieudane odtworzenie może dotknąć kilku aplikacji naraz.

Instalacja i konfiguracja

Uruchomienie kontenerów to dopiero pierwszy krok. DNS, TLS, URI przekierowań, claimy tokenów, mapowania grup, dostarczanie e-maili i dostęp awaryjny to miejsca, w których wdrożenie SSO zaczyna stawać się infrastrukturą, a nie kolejną aplikacją Docker.

Zasoby serwera

IdP to tylko część budżetu zasobów. PostgreSQL, reverse proxy, workery, haszowanie haseł, logi i synchronizacja katalogów mogą konkurować o CPU i pamięć, gdy dzielą jeden VPS.

Zarządzanie bazą danych i kopiami zapasowymi

Authentik, ZITADEL i typowe produkcyjne wdrożenia Keycloak zależą od bazy danych. Rób kopię tej bazy poza serwerem, udokumentuj sposób jej odtworzenia i przetestuj odtwarzanie. Udane zadanie kopii zapasowej to nie to samo co działająca procedura odtwarzania.

Ryzyko blokady i odtwarzania

Zły URI przekierowania, wygasły sekret klienta, zerwane połączenie z katalogiem lub zbyt restrykcyjna polityka mogą zablokować administratorów razem ze wszystkimi innymi. Utrzymuj ścieżkę odzyskiwania, która nie zależy od przepływu uwierzytelniania, który próbujesz naprawić.

Utrzymanie dostępności IdP

Awaria IdP niekoniecznie od razu kończy każdą istniejącą sesję aplikacji. Trwające sesje mogą działać, dopóki nie wygasną ich własne tokeny lub ciasteczka, ale nowe logowania i odświeżenia tokenów mogą się nie udać. Przetestuj ten tryb awarii, zanim uczynisz SSO obowiązkowym w całym stosie.

Kiedy nie powinieneś samodzielnie hostować SSO

Samodzielne hostowanie przestaje się opłacać, gdy twój zespół nie potrafi odtworzyć i obsługiwać warstwy tożsamości z niezawodnością, jakiej wymagają twoje aplikacje.

Kiedy zarządzana tożsamość jest bezpieczniejsza

Zarządzana tożsamość jest warta swojej ceny, gdy koszt obsługi IdP przewyższa kontrolę, jaką zyskujesz dzięki samodzielnemu hostowaniu. Usługi takie jak Auth0, Clerk, WorkOS i Microsoft Entra ID przenoszą na dostawcę dużą część odpowiedzialności za dostępność platformy, łatanie i utrzymanie infrastruktury.

Nadal odpowiadasz za konfigurację aplikacji, uprawnienia i planowanie odtwarzania, ale już nie za utrzymanie samej platformy tożsamości online.

Kiedy twój zespół nie poradzi sobie z przestojem

Jeśli nikt w zespole nie potrafi podczas awarii odtworzyć IdP, naprawić PostgreSQL, wymienić wygasłego sekretu lub zdiagnozować nieudanego połączenia federacyjnego, samodzielne hostowanie tożsamości może być złym kompromisem operacyjnym.

Awaria wykracza poza jedną niedostępną aplikację. Nowe logowania i odświeżenia tokenów w kilku aplikacjach mogą zawieść jednocześnie.

Kiedy wymagania zgodności są zbyt wysokie

Self-hosted tożsamość można stosować w środowiskach regulowanych, ale samodzielne uruchamianie oprogramowania nie tworzy automatycznie mechanizmów kontroli ani dowodów, których oczekuje audytor. Twój zespół nadal odpowiada za logowanie zdarzeń, przeglądy dostępu, kopie zapasowe, zarządzanie zmianami, dostępność, reagowanie na incydenty i całą dokumentację, której wymaga obowiązujący standard.

Self-hosted SSO nie jest symbolem statusu. Jeśli twój zespół nie potrafi bezpiecznie obsługiwać warstwy tożsamości, płacenie za zarządzaną tożsamość może być lepszą decyzją inżynierską.

W czym pomaga Cloudzy

Cloudzy zmienia warstwę wdrożenia; nie eliminuje opisanej wyżej pracy przy konfiguracji tożsamości i utrzymaniu.

Problem z ręcznym wdrażaniem SSO

Ręczne wdrożenie SSO oznacza przygotowanie serwera, instalację aplikacji i bazy danych, konfigurację reverse proxy, ustawienie DNS i TLS, a dopiero potem rozpoczęcie właściwej konfiguracji tożsamości. Nic z tego nie zastępuje późniejszej pracy nad OIDC, SAML, katalogiem czy politykami.

Wdrożenie SSO jednym kliknięciem na Cloudzy

Cloudzy oferuje wdrożenia jednym kliknięciem dla Authentik i Keycloak. Aplikacja Authentik na jedno kliknięcie jest w marketplace Cloudzy. Aplikacja Keycloak na jedno kliknięcie również jest w marketplace Cloudzy. ZITADEL nie ma dziś w marketplace, więc wdróż go za pomocą jego konfiguracji Docker Compose na standardowym VPS. Instalacja jednym kliknięciem uruchamia bazową aplikację, a konfiguracja tożsamości, DNS, kopie zapasowe, aktualizacje, polityki i testy odtwarzania pozostają pod twoją kontrolą.

Kiedy użyć osobnego VPS dla swojego IdP

Hostowanie IdP razem z aplikacjami jest rozsądne w homelabie, gdzie przestój jest akceptowalny. W stosie krytycznym dla biznesu wydzielenie dostawcy tożsamości usuwa oczywistą wspólną domenę awarii: restart, wyczerpanie zasobów lub kompromitacja serwera aplikacji nie pociąga już za sobą warstwy tożsamości.

Osobny VPS to nie to samo co wysoka dostępność, ale daje IdP własny budżet zasobów, własny harmonogram konserwacji i własną granicę odtwarzania.

Zalecenia dotyczące rozmiaru VPS

Dobieraj rozmiar całego stosu, nie tylko procesu IdP, zwłaszcza gdy PostgreSQL i reverse proxy dzielą ten sam VPS.

Wymagania VPS dla Authentik

Oficjalna dokumentacja Docker Compose Authentik wymaga hosta z co najmniej 2 rdzeniami CPU i 2 GB RAM. To właściwy punkt startu dla małego wdrożenia. Daj serwerowi więcej zapasu, gdy ten sam host dzielą PostgreSQL, dodatkowe outposty, synchronizacja katalogów lub większy ruch logowań.

Wymagania VPS dla ZITADEL

Oficjalne wdrożenie ZITADEL przez Docker Compose wymaga co najmniej 2 GB RAM dla hosta. Dobierz rozmiar VPS typu wszystko w jednym dla ZITADEL, jego interfejsu logowania, PostgreSQL i reverse proxy razem, zamiast traktować usługę Go w izolacji.

Wymagania VPS dla Keycloak

Dokumentacja kontenerów Keycloak zaleca limit pamięci 2 GB dla mniejszych, gotowych na produkcję wdrożeń Keycloak. Ta liczba dotyczy samego kontenera Keycloak, a nie całego VPS, na którym działa też PostgreSQL.

Jeśli Keycloak i PostgreSQL dzielą jeden VPS, 4 GB RAM systemowego to rozsądny punkt startu. Traktuj to jako praktyczną wskazówkę dla hosta, a nie oficjalne minimum Keycloak.

Wymagania VPS dla Authelia

Authelia nie publikuje bezpośrednio porównywalnego minimum serwera 1 GB czy 2 GB. Dobierz rozmiar hosta dla Authelia razem z reverse proxy, backendem magazynu, katalogiem użytkowników i wszelkimi innymi usługami dzielącymi maszynę.

Authelia ma zwykle mniejszy ślad wdrożeniowy niż pełny IdP obok PostgreSQL, ale rzeczywiste wymagania VPS zależą od reszty stosu.

Przykładowa konfiguracja: Authentik z Vaultwarden

Vaultwarden dodał natywną obsługę SSO przez OpenID Connect w wersji 1.35.0 w grudniu 2025 roku. Authentik jest użytecznym przykładem, bo integracja odsłania elementy OIDC, które spotkasz też w innych aplikacjach: URI przekierowań, poświadczenia klienta, zakresy, adresy URL wystawcy i dostęp awaryjny.

Podstawowa konfiguracja Authentik

W Authentik:

1. Utwórz niestandardowe mapowanie zakresu e-mail dla Vaultwarden. Vaultwarden wymaga, aby zakres email zwracał albo email_verified: true, albo w ogóle nie zawierał wartości email_verified, podczas gdy domyślny zakres e-mail Authentik zwraca obecnie false.
2. Utwórz parę aplikacja i dostawca OAuth2/OpenID Connect.
3. Dodaj https://vault.example.com/identity/connect/oidc-signin jako ścisły URI przekierowania typu Authorization.
4. Wybierz dowolny dostępny klucz podpisu.
5. Zanotuj Client ID, Client Secret i slug aplikacji.
6. Ustaw ważność tokenu dostępu na więcej niż pięć minut.
7. Dodaj mapowanie offline_access z Authentik do wybranych zakresów.
8. Zastąp domyślne mapowanie e-mail niestandardowym mapowaniem zweryfikowanego e-maila z kroku 1.

Podstawowa konfiguracja OIDC w Vaultwarden

Użyj:

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

Zastąp przykładowe domeny, slug aplikacji, identyfikator klienta i sekret klienta wartościami z własnego wdrożenia, a następnie zrestartuj Vaultwarden.

CZYTAJ

Self-hosting menedżera haseł Bitwarden: kompletny przewodnik

Co przetestować przed wymuszeniem SSO

Zostaw SSO_ONLY ustawione na false, gdy testujesz logowanie, wylogowanie, odświeżanie tokenów, dopasowanie kont i odtwarzanie. Sprawdź też, co się dzieje, gdy Authentik jest tymczasowo niedostępny.

Gdy zarówno SSO, jak i odtwarzanie działają zgodnie z oczekiwaniami, możesz zdecydować, czy wymaganie SSO przy każdym logowaniu ma sens w twoim wdrożeniu.

Te same koncepcje OIDC dotyczą innych aplikacji self-hosted, ale URI przekierowań, zakresy, claimy i licencje się różnią. Sprawdzaj dokumentację SSO każdej aplikacji zamiast kopiować konfigurację Vaultwarden wprost.

Kiedy Authelia jest lepsza niż pełny IdP

Authelia staje się atrakcyjniejsza, gdy aplikacja w ogóle nie musi rozumieć dostawcy tożsamości.

Uwierzytelnianie na reverse proxy

Authelia jest zaprojektowana głównie do ochrony aplikacji na warstwie reverse proxy. Definiujesz reguły kontroli dostępu, a Authelia decyduje, czy żądanie ma dotrzeć do backendu, zanim sama aplikacja zajmie się uwierzytelnianiem.

Ochrona aplikacji bez OIDC

To przydatne dla starszych wewnętrznych narzędzi, dashboardów i usług, które nie obsługują OIDC ani SAML. Zamiast modyfikować każdą aplikację, możesz postawić uwierzytelnianie przed nią, na reverse proxy.

Authelia może też działać jako dostawca OIDC, ale uwierzytelnianie na reverse proxy pozostaje jej główną siłą.

Używanie Authelia razem z Authentik

Możesz używać Authentik dla aplikacji obsługujących OIDC lub SAML, a Authelia dla aplikacji, które potrzebują uwierzytelniania na reverse proxy.

Niekoniecznie potrzebujesz obu. Authentik również obsługuje ochronę aplikacji przez proxy, więc używanie Authelia obok niego ma sens tylko wtedy, gdy przepływ reverse proxy Authelia rozwiązuje konkretną część twojego stosu czyściej.

Często zadawane pytania

Czy Authentik jest lepszy niż Keycloak?

Dla większości homelabów i małych stosów aplikacji self-hosted Authentik jest łatwiejszy do opanowania. Jego przepływ administracyjny skupia się na aplikacjach, dostawcach, grupach i politykach, nie odsłaniając naraz tak dużej złożoności IAM.

Keycloak ma więcej sensu, gdy potrzebujesz konkretnie jego głębszej federacji, modelu realmów lub Authorization Services. Authentik jest mocniejszym domyślnym wyborem dla prostszego self-hosted SSO; Keycloak pasuje do środowisk, które potrzebują tych dodatkowych mechanizmów kontroli.

Czy ZITADEL jest lepszy niż Keycloak?

ZITADEL pasuje lepiej, gdy budujesz produkt i chcesz tożsamości sterowanej przez API, organizacji i wielodostępności. Keycloak pasuje lepiej, gdy potrzebujesz jego głębszego modelu autoryzacji, rozbudowanych mechanizmów federacji lub środowiska już zbudowanego wokół Keycloak.

Jaka jest różnica między Authentik a Authelia?

Authentik to pełny dostawca tożsamości zbudowany wokół użytkowników, grup, aplikacji, dostawców, przepływów i polityk. Aplikacje mogą integrować się z nim bezpośrednio przez protokoły takie jak OIDC i SAML.

Authelia koncentruje się na uwierzytelnianiu i kontroli dostępu na reverse proxy. Zawiera też dostawcę OIDC, ale ochrona na reverse proxy pozostaje jej głównym zastosowaniem.

Wybierz Authentik, gdy aplikacje integrują się bezpośrednio z IdP. Wybierz Authelia, gdy uwierzytelnianie musi się odbywać głównie zanim ruch dotrze do aplikacji.

Czy mogę uruchomić Authentik na VPS z 1 GB?

Nie jako wspierany punkt startu. Aktualna dokumentacja Docker Compose Authentik wymaga co najmniej 2 rdzeni CPU i 2 GB RAM. Obecne podstawowe wdrożenie używa serwera Authentik, workera i PostgreSQL; Redis został całkowicie usunięty w Authentik 2025.10.

Przyjmij 2 GB jako minimalny punkt startu dla małej instalacji i dodaj zapas, gdy inne usługi dzielą maszynę.

Czy Vaultwarden obsługuje SSO przez OIDC?

Tak. Vaultwarden dodał obsługę SSO przez OpenID Connect w wersji 1.35.0 w grudniu 2025 roku. Wymaga zewnętrznego dostawcy OIDC, takiego jak Authentik, Keycloak lub ZITADEL.

Dokładna konfiguracja zależy od dostawcy. W aktualnych wydaniach Authentik udokumentowana integracja obejmuje niestandardowe mapowanie zakresu zweryfikowanego e-maila, offline_access, poświadczenia klienta i adres URL wystawcy aplikacji Authentik.

Czy uruchamiać IdP na tym samym VPS co aplikacje?

W homelabie, gdzie przestój jest akceptowalny, wspólne hostowanie może być rozsądne. Dla aplikacji krytycznych dla biznesu osobny VPS daje dostawcy tożsamości własny budżet zasobów i usuwa serwer aplikacji ze wspólnej domeny awarii.

Samo w sobie nie tworzy to wysokiej dostępności, ale restart serwera aplikacji, problem z zasobami lub kompromitacja nie pociąga już automatycznie za sobą IdP.

Które self-hosted SSO jest najłatwiejsze w użyciu?

Authentik jest najłatwiejszym punktem startu dla większości osób podłączających istniejące aplikacje self-hosted. Jego interfejs administracyjny czyni aplikacje, dostawców, grupy i polityki bardziej przystępnymi niż szerszy model realmów i autoryzacji Keycloak.

Authelia może być prostsza, gdy potrzebujesz tylko uwierzytelniania na reverse proxy. ZITADEL ma więcej sensu, gdy osobą konfigurującą tożsamość jest deweloper pracujący głównie przez API.