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

Jeśli sprawdzałeś cenniki niektórych platform CIAM w modelu SaaS, pewnie zauważyłeś, jak drogie potrafią być, i najprawdopodobniej rozważałeś rozwiązanie hostowane samodzielnie.

Ten artykuł dotyczy czterech samodzielnie hostowanych platform CIAM, które mały zespół SaaS B2B faktycznie utrzyma, nie zamieniając tego w drugi etat: ZITADEL, FusionAuth, Logto i Ory Hydra. Nie wszystkie mają ten sam kształt, a właściwy wybór zależy mniej od listy funkcji, a bardziej od tego, jaki produkt B2B budujesz. Uruchomiłem je obok siebie na jednym VPS przez tydzień, żeby przygotować to porównanie, a poniżej znajdziesz wersję, którą wysłałbym założycielowi piszącemu do mnie w sprawie CIAM.

Jedno zastrzeżenie na start: mowa o CIAM jako funkcji produktu, a nie o wewnętrznym SSO dla własnego zespołu.

Krótka wersja

Cztery samodzielnie hostowane platformy CIAM, po jednym zdaniu na każdą:

• ZITADEL jeśli chcesz wielodostępności i organizacji B2B od razu po instalacji.
• FusionAuth jeśli chcesz dopracowanego panelu administracyjnego i długiej, przewidywalnej historii wydań.
• Logto jeśli chcesz najczystszego doświadczenia dewelopera już pierwszego dnia.
• Ory Hydra jeśli budujesz na poziomie protokołu i chcesz silnika OAuth 2.0, a nie gotowej aplikacji logowania.

Krótko mówiąc: ZITADEL to najbezpieczniejszy pierwszy wybór dla typowego SaaS B2B, a reszta artykułu rozkłada to uzasadnienie na czynniki pierwsze.

Dlaczego CIAM to inna decyzja niż SSO dla pracowników

Jeśli SSO dla twojego wewnętrznego zespołu przestanie działać, szkody zwykle są ograniczone. Inżynierowie mogą na godzinę stracić dostęp do Grafany albo innego wewnętrznego narzędzia. Jeśli padnie CIAM, płacący klienci w ogóle nie zalogują się do produktu. To zmienia pytanie z „które narzędzie uwierzytelniania jest wygodne dla naszego zespołu?” na „któremu systemowi uwierzytelniania możemy zaufać jako części samego produktu?”

CIAM, czyli rodzaj infrastruktury tożsamości, jakiej potrzebuje SaaS B2B, wymaga też prymitywów, których wiele narzędzi SSO dla pracowników nie eksponuje. Twój klient to nie pojedynczy użytkownik, tylko organizacja (tenant) z własnymi użytkownikami, rolami, brandingiem i być może własnym połączeniem SAML do korporacyjnego IdP. Nie uwierzytelniasz wyłącznie ludzi, tylko izolujesz użytkowników jednej firmy od użytkowników drugiej wewnątrz tego samego produktu. To właśnie ten kształt B2B biorą na cel cztery narzędzia opisane niżej, każde na swój sposób. Keycloak ma już pełnoprawne Organizations, więc odrzucanie go jako narzędzia wyłącznie dla pracowników byłoby nieaktualne; wyjaśniam jego nieobecność w FAQ.

Trójkąt zbuduj / kup / hostuj samodzielnie wygląda tu inaczej. Pisanie OAuth od zera to błąd na własne życzenie. Wypuszczasz produkt SaaS, a nie dostawcę tożsamości. Kupno usługi zarządzanej (Auth0, Clerk, WorkOS) jest właściwe, gdy zespół nie ma żadnych mocy przerobowych na ops, a budżet jest rozsądny. Nigdy nie doradziłbym dwuosobowemu startupowi samodzielnego hostowania uwierzytelniania pierwszego dnia. Własny hosting staje się racjonalny, gdy cena za MAU w zarządzanym CIAM przekracza koszt infrastruktury plus bieżący czas inżynierów, albo gdy potrzebujesz bezpośredniej kontroli nad wdrożeniem i warstwą danych. W zespołach, z którymi pracowałem, ten moment wypada zwykle gdzieś między „mamy prawdziwy produkt” a „mamy prawdziwy dział customer success”.

Jeśli szukasz SSO dla własnych aplikacji, a nie aplikacji swoich klientów, to jest inne porównanie niż to. Przechodzimy do naszych typów.

Cztery narzędzia, po kolei

Wybrałem te cztery, bo są na tyle CIAM-owe, że da się je oceniać jako infrastrukturę produktu, a nie tylko wewnętrzne SSO. ZITADEL, FusionAuth, Logto i Ory dają realną ścieżkę samodzielnego hostowania i wystarczającą trakcję, by traktować je poważnie. Opcje będące wyłącznie biblioteką, te nastawione na SSO pracownicze i mniej dojrzałe lepiej omówić w FAQ.

ZITADEL

ZITADEL to platforma tożsamości pochodzenia szwajcarskiego napisana w Go, z architekturą event-sourced i backendem PostgreSQL. Na 27 lipca 2026 jej najnowsze wydanie na GitHubie to the 4.16 series, current as of July 2026. ZITADEL przeszedł z Apache 2.0 na AGPL-3.0 począwszy od v3; przy zwykłym użyciu SaaS praktyczne skutki są zwykle mniej straszne, niż brzmią, a szczegóły omawiam w FAQ.

Co wyróżnia ZITADEL w kontekście SaaS B2B: organizacje i wielodostępność to prymitywy pierwszej klasy, a nie funkcje, które sklejasz z generycznych obiektów. Tworzysz Organization, dostaje ona własnych użytkowników, polityki, branding i ustawienia dostępu, a ty możesz przypisać jej projekty, żeby jej administratorzy zarządzali przydziałem ról własnym użytkownikom. Nie musisz wymyślać pojęcia „tenant” nad generycznymi użytkownikami. Zaczynasz od niego.

Doświadczenie dewelopera jest API-first: aktualne zasobowe API REST v2 plus dostęp gRPC i REST do starszych usług v1. Oficjalne i społecznościowe SDK obejmują popularne stosy serwerowe. Konsola administracyjna jest funkcjonalna, ale skromniejsza niż w FusionAuth.

Moja ocena: Jeśli budujesz SaaS B2B i wiesz, że będziesz mieć tenantów, zacząłbym od ZITADEL. Spośród opcji hostowanych samodzielnie to ta najwyraźniej zaprojektowana wokół problemu logowania w B2B.

FusionAuth

FusionAuth to amerykańska platforma firmy Inversoft, LLC (spółka LLC z Delaware działająca jako FusionAuth), która jest na rynku dłużej niż pozostała trójka, i to widać, w dobrym sensie. Panel administracyjny sprawia wrażenie wyraźnie lepiej zaprojektowanego niż reszta, dokumentacja jest dojrzała, a rytm wydań stabilny, a nie zawrotny. Jeśli kiedykolwiek odziedziczyłeś czteroletnią integrację uwierzytelniania i po cichu podziękowałeś poprzedniemu inżynierowi za wybór nudnej opcji, FusionAuth jest tą wersją CIAM, która na takie podziękowanie zasługuje.

Ludzie potykają się o licencję: FusionAuth Community można hostować samodzielnie za darmo, ale rdzeń produktu nie jest open source. Produkt podlega własnej licencji FusionAuth, a te ograniczenia mają znaczenie, jeśli planujesz redystrybucję, osadzanie, zmianę marki, odsprzedaż lub hostowanie FusionAuth dla własnych klientów. Samodzielnie hostowana wersja Community pokrywa podstawowy przypadek SaaS B2B; płatne plany dokładają funkcje takie jak SAML inicjowany przez IdP, zaawansowane MFA i motywy specyficzne dla aplikacji, natomiast SCIM, Tenant Manager i polityki MFA na poziomie aplikacji siedzą w Enterprise.

Co do kształtu B2B: FusionAuth modeluje tenantów i aplikacje, ale abstrakcja to raczej „konteneryzowane uwierzytelnianie na tenanta” niż „organizacje B2B jako obiekt domenowy”. Działa (wypuszczałem na tym produkty), ale wielodostępność bardziej przypomina prymityw izolacji niż pełnoprawny model B2B. Oficjalne SDK i biblioteki klienckie są liczne:

• Angular
• React
• Vue
• iOS
• Android
• Go
• Java
• .NET
• PHP
• Python
• Ruby
• TypeScript

Biblioteki serwerowe to cienkie klienty API. Konsolę administracyjną łatwiej niż pozostałe przekazać osobie z operacji bez zaplecza inżynierskiego.

Moja ocena: Jeśli twój zespół ceni dopracowany interfejs i długą, przewidywalną historię bardziej niż natywne prymitywy B2B, to FusionAuth. To najbardziej „nudny” wybór na tej liście, i to komplement.

Logto

Logto jest najnowszy z tej czwórki, rozwijany przez Silverhand Inc. i na licencji MPL-2.0, i to on najwyraźniej dba o swój panel. Uruchomienie pierwszego dnia idzie stosunkowo szybko. Provisionujesz, przeklikujesz kreatora i po jakichś piętnastu minutach masz działającego dostawcę OIDC z przyzwoitym domyślnym interfejsem logowania (zmierzyłem to w tygodniu, gdy uruchomiłem całą czwórkę obok siebie). Oficjalne przewodniki startowe obejmują nowoczesne frameworki i stosy serwerowe, więc jeśli twój stack to „Next.js + Postgres + coś”, poczujesz się jak u siebie.

Jego odpowiedź na B2B nazywa się Logto Organizations. Pokrywa podstawowe prymitywy B2B: członkostwo w organizacji, role o zasięgu organizacji, zaproszenia dla członków, provisioning just-in-time i integrację z korporacyjnym SSO. Model organizacji jest młodszy niż w ZITADEL, więc każdy nietypowy przepływ SAML, SCIM lub federacyjny przetestowałbym z docelowymi klientami, zanim się zdecydujesz.

Kompromisem jest dojrzałość: Logto to najnowsza opcja na tej liście. Roadmapa pędzi, co jest świetne, gdy pojawia się potrzebna funkcja, i niewygodne, gdy pojawia się zmiana łamiąca zgodność. Jeśli twój SaaS B2B leży po prostszej stronie spektrum wielodostępności (niewielka liczba organizacji i brak egzotycznych wymagań federacyjnych), doświadczenie dewelopera w Logto ułatwia resztę decyzji.

Moja ocena: Jeśli chcesz najszybszego pierwszego dnia, a twoje potrzeby B2B są wciąż stosunkowo proste, to Logto.

Ory Hydra (i stos Ory)

Ory Hydra to serwer OAuth 2.0 / OpenID Connect z ekosystemu Ory, na licencji Apache-2.0. Pełny stos Ory łączy Hydrę z Ory Kratos (tożsamość i zarządzanie użytkownikami, samoobsługowe logowanie, rejestracja, MFA i odzyskiwanie konta), Ory Keto (serwer autoryzacji w stylu Zanzibar pełniący rolę punktu decyzyjnego polityk) oraz Ory Oathkeeper (proxy tożsamości i dostępu, które uwierzytelnia, autoryzuje i modyfikuje przychodzące żądania HTTP). Składasz to, czego potrzebujesz. Wszystko napisano w Go, a API są czyste.

Haczyk (i to nie wada; dla właściwego zespołu to zaleta) polega na tym, że Hydra jest silnikiem, a nie aplikacją. Z założenia Hydra łączy się z osobną aplikacją logowania i zgód , którą sam dostarczasz. Jeśli chcesz gotowy ekran logowania, to nie jest narzędzie dla ciebie. Jeśli budujesz coś, w czym przepływ uwierzytelniania jest częścią produktu (platforma dla deweloperów, autorski portal B2B albo produkt API-first z własnym onboardingiem), brak narzuconego interfejsu jest dokładnie tym, czego chcesz.

Historia B2B jest komponowalna, a nie „pod klucz”. Wielodostępność zamodelujesz, podłączając schematy Kratosa i relacje Keto do własnej warstwy organizacji, i to działa, ale to ty prowadzisz okablowanie. Kosztem jest więcej hydrauliki, zyskiem kontrola nad doświadczeniem. Dokumentacja Ory szczegółowo opisuje powierzchnię protokołu, ale model komponowalny zakłada, że sam chcesz podejmować decyzje na poziomie protokołu. Jeśli „audience claim” albo „PKCE” nic ci nie mówią, zacznij od jednej z pozostałych trzech.

Moja ocena: Jeśli budujesz coś na poziomie protokołu (bramka uwierzytelniania, własne przepływy, platforma dla deweloperów), a standardowe aplikacje wydają się ograniczające, Ory jest właściwą odpowiedzią. Dla typowego SaaS B2B, który chce mieć działające logowanie dziś, nie jest.

Porównanie w skrócie

Oto podsumowanie czterech narzędzi w jednej tabeli, przydatne przy drugim przejściu, nie jako zamiennik profili powyżej.

Od którego zacząć?

Cztery krótkie scenariusze, które obejmują większość zespołów, z którymi bym o tym rozmawiał.

Budujesz SaaS B2B i wiesz, że będziesz mieć tenantów. Zacznij od ZITADEL. Prymitywy wielodostępności i organizacji zaprojektowano dokładnie do tego, powierzchnia API jest kompletna, a na wymyślanie modelu tenanta zejdzie ci mniej czasu niż przy pozostałej trójce. Przejście na AGPL zasługuje na przegląd prawny, ale niemodyfikowane, osobno zintegrowane wdrożenie to zwykle prosty przypadek użycia SaaS.

Chcesz dopracowanego panelu administracyjnego i stabilnej, przewidywalnej platformy. FusionAuth. Plan Community pokrywa podstawowe potrzeby wielu zespołów; zarezerwuj czas na uważne przeczytanie licencji i macierzy funkcji. Funkcje takie jak SAML inicjowany przez IdP, zaawansowane MFA i motywy specyficzne dla aplikacji wymagają planu płatnego, natomiast SCIM, Tenant Manager i polityki MFA na poziomie aplikacji siedzą w Enterprise.

Twoje potrzeby B2B są dziś proste i chcesz najszybszego pierwszego dnia. Logto. Jego doświadczenie dewelopera pierwszego dnia było najszybsze w moim teście porównawczym. Przyjmij, że stawiasz na młodszy ekosystem, i wróć do tej decyzji, jeśli wymagania urosną do przypadków brzegowych federacji, których nie przetestowałeś.

Budujesz coś, w czym przepływy uwierzytelniania są częścią doświadczenia produktu. Ory Hydra (plus Kratos, plus Keto, jeśli potrzebujesz uprawnień). Napiszesz więcej kodu. Będziesz mieć więcej kontroli. Jeśli ten kompromis nie jest dla ciebie oczywisty, nie jesteś odbiorcą Ory. Wybierz jedno z pozostałych trzech.

Jeśli dwa z tych opisów pasują do ciebie, domyślnie wybierz ZITADEL. Pasuje najszerzej i to jego dałbym małemu zespołowi założycielskiemu bez zadawania wielu dodatkowych pytań.

Ile kosztuje cię własny hosting (operacyjnie)

Teraz nieromantyczna część artykułu.

Twoja dyscyplina kopii zapasowych PostgreSQL staje się teraz czymś, od czego zależy biznes. W tych wdrożeniach stan tożsamości, który musisz chronić, może obejmować rekordy użytkowników, zahaszowane poświadczenia, sekrety MFA, poświadczenia klienta OAuth i dane sesji. Strać ten stan, a klienci mogą stracić możliwość logowania. Ustaw automatyczne kopie zanim zarejestruje się pierwszy prawdziwy użytkownik, przetestuj odtwarzanie i wrzuć zdrowie kopii do tego samego kanału alertów co dostępność aplikacji.

Tempo wydań zmienia się w czasie. ZITADEL v4.16.1 ukazał się 17 lipca 2026 po kilku czerwcowych wydaniach, a każdy projekt tutaj utrzymuje własną kadencję i politykę zgodności. Traktuj tę kadencję jako kwestię utrzymania, a nie skrót do oceny jakości. Przeczytaj notatki wydania, zanim uruchomisz docker compose pull, i zaplanuj cykliczne okno łatek. Pomijanie aktualizacji dostawcy tożsamości przez miesiące może zostawić cię w tyle za poprawkami bezpieczeństwa i zgodności podczas pierwszego prawdziwego audytu.

Przyziemne rzeczy, które zawsze cię dopadają: odnawianie certyfikatów TLS (użyj reverse proxy z Let's Encrypt, zautomatyzuj odnowienia i ustaw alerty na błędy), konfiguracja poczty wychodzącej dla maili weryfikacyjnych i resetów hasła (SES, SendGrid, Postmark: wybierz jeden i porządnie skonfiguruj SPF/DKIM/DMARC, inaczej maile z resetem trafią do spamu), rotacja poświadczeń klienta OAuth, gdy odchodzi inżynier, oraz limitowanie żądań na endpointach logowania, żeby atak credential stuffing nie zajechał ci procesora.

Wskazówka: jeśli używasz zarządzanego Postgresa, nie zakładaj, że użytkownik bazy z czasu działania może też utworzyć schemat. Utwórz bazę i użytkownika z wyprzedzeniem, nadaj wymagane uprawnienia właściciela lub instalacyjne i uruchom pierwszą konfigurację poświadczeniami, których oczekuje dane narzędzie. Inaczej pierwsze uruchomienie może paść na mglistym błędzie uprawnień bazy, a ty spalisz godzinę na gonieniu nie tego tropu.

To, co droga własnego hostingu oszczędza ci w dolarach, zabiera w odpowiedzialności. Po instalacji zaplanuj kilka godzin inżynierskich miesięcznie na utrzymanie warstwy tożsamości w formie. Zespoły, które nie przeznaczają na to żadnego czasu, odkrywają koszt później: podczas awarii, przy dziwnym przypadku brzegowym SAML albo przy pierwszym audycie bezpieczeństwa.

Gdzie je wdrożyć

Linuksowy VPS z Docker Compose może być rozsądnym punktem wyjścia do ewaluacji i skromnych obciążeń, ale wymiarowanie produkcyjne i wysoka dostępność zależą od ruchu, wymagań bezpieczeństwa i twojej tolerancji na przestoje. Oto jak wypadają typowe opcje wdrożenia:

• Hosting współdzielony nie uruchomi żadnego z nich. Potrzebują trwałego magazynu, własnych portów, dostępu root do środowiska kontenerów i prawdziwego backendu bazodanowego. PostgreSQL to domyślna ścieżka dla większości tej listy, ale dosłownie nie jest jedyną obsługiwaną bazą dla każdego narzędzia.
• Kubernetes uruchomi wszystkie cztery, ale ścieżka oficjalna jest nierówna. ZITADEL, FusionAuth oraz Ory publikują oficjalne charty Helm, podczas gdy dokumentacja samodzielnego hostowania Logto skupia się na wdrożeniu w Dockerze i na maszynach wirtualnych. Dla małego SaaS B2B, który nie doszedł jeszcze do punktu, w którym Kubernetes zwraca się gdzie indziej, to zwykle przeinżynierowanie. Sięgnij po niego, gdy reszta twojej infrastruktury już tam jest.
• Bare metal jest w porządku, jeśli już na nim jesteś. Większość zespołów SaaS B2B nie jest.

Przy małym pilotażu na jednym węźle zacząłbym od 4 GB RAM, 2 vCPU i 60 GB pamięci NVMe, a potem obciążył testami prawdziwy przepływ logowania. To baza do planowania, a nie uniwersalne minimum produkcyjne. Aplikacje są względnie lekkie, ale PostgreSQL potrzebuje pamięci, a haszowanie haseł zapasu CPU. Wytyczne produkcyjne ZITADEL zalecają udostępnienie czterech rdzeni CPU na szczyty haszowania haseł.

Gdy produkt stanie się realny, a ruch stały, skaluj na podstawie pomiarów. Szybki magazyn pomaga opóźnieniom PostgreSQL, a zapas CPU liczy się przy równoległym haszowaniu haseł. Obserwuj pamięć, I/O bazy, opóźnienie logowania i wysycenie CPU zamiast zakładać, że jeden zasób jest najważniejszy.

Uruchomienie CIAM na produkcji oznacza, że jego dostępność staje się twoim problemem. My korzystamy z instancji Cloudzy Linux VPS do tego typu obciążeń, z pamięcią NVMe i SLA dostępności 99,95% na platformie bazowej. Cloudzy oferuje też VPS z ZITADEL jednym kliknięciem jeśli wolisz pominąć początkowy skrypt provisioningu; pozostała trójka udostępnia oficjalne obrazy kontenerów do instalacji opartej na Dockerze. Menedżerskie spojrzenie na to, jak kontrola dostępu wpisuje się w resztę twojej postawy bezpieczeństwa, daje przewodnik po dobrych praktykach IAM ujmujący temat od strony polityk.

Często zadawane pytania

Czy licencja AGPL ZITADEL dotyczy mojego SaaS?

Zwykle nie przy niemodyfikowanym, osobno zintegrowanym wdrożeniu, ale to nie jest porada prawna. Obowiązki AGPL ZITADEL dotyczą samego ZITADEL. Jeśli zmodyfikujesz ZITADEL i będziesz udostępniać tę zmodyfikowaną wersję jako usługę sieciową, licencja może wymagać udostępnienia odpowiadającego kodu źródłowego na AGPL. Opublikowane stanowisko ZITADEL mówi, że samo używanie niemodyfikowanej instancji jako usługi tożsamości twojego SaaS nie wymaga samo w sobie licencjonowania twojej odrębnej aplikacji na AGPL. Przeczytaj ogłoszenie licencyjne ZITADEL i zasięgnij porady prawnej, jeśli modyfikujesz, redystrybuujesz, osadzasz lub oferujesz oprogramowanie osobom trzecim. Dostępna jest też licencja komercyjna.

Dlaczego Keycloak ani Authentik nie ma na tej liście?

Keycloak i Authentik to świetne samodzielnie hostowane narzędzia tożsamości (używam ich), ale wykluczenie Keycloaka z powodu braku organizacji B2B byłoby dziś błędem: bieżące wydania Keycloaka zawierają Organizations, grupy organizacji i mechanizmy delegowanej administracji. Pominąłem go, bo to porównanie skupia się na czterech opcjach z bardziej bezpośrednią ścieżką dla małego zespołu SaaS B2B; Keycloak zasługuje na własną ocenę, gdy liczy się utrzymanie JVM, głębia ekosystemu i elastyczność na poziomie realmów. Authentik nadal lepiej pasuje do SSO pracowniczego i aplikacji wewnętrznych niż do produktowego modelowania tenantów.

Czy własny hosting jest tańszy niż Auth0?

Przy niskich MAU często nie. Twoje godziny inżynierskie kosztują więcej niż rachunek z Auth0 na progu wczesnego startupu. Własny hosting wygrywa ekonomicznie przy skali, w której cena za MAU zarządzanego CIAM przekracza łączny koszt małego VPS plus tych kilku godzin inżynierskich miesięcznie. Dokładny punkt zwrotu zależy od kosztu godziny twojego zespołu, krzywej wzrostu MAU i tego, czy produkt potrzebuje funkcji enterprise, które wypychają cię na droższe poziomy Auth0. Traktuj oszczędności jako realne, ale nie natychmiastowe.

Jaki jest minimalny rozmiar VPS dla produkcyjnego CIAM?

Przy małym pilotażu na jednym węźle 4 GB RAM, 2 vCPU i pamięć NVMe to rozsądny punkt wyjścia, a nie gwarancja produkcyjna. Wymiaruj na podstawie rozmiaru bazy, równoległego obciążenia logowaniami, kosztu haszowania haseł i celu dostępności. Własne wytyczne produkcyjne ZITADEL zalecają cztery dostępne rdzenie CPU na szczyty haszowania; inne narzędzia i wzorce ruchu wymagają własnych testów obciążeniowych.

Czy mogę później przejść z zarządzanego CIAM na własny hosting?

Tak, ale zaplanuj to jak prawdziwy projekt. Resety haseł nie są nieuniknione: możliwość eksportu i obsługiwane formaty haszy różnią się, a niektóre cele obsługują masową lub just-in-time migrację użytkowników , podczas gdy inne wymuszają reset. Czynniki MFA, klienty OAuth, aktywne sesje, stan weryfikacji e-mail oraz mapowania tenantów i ról wymagają osobnego potraktowania. Jeśli już podejrzewasz, że później przejdziesz na własny hosting, spisz te ograniczenia eksportu i migracji, zanim wybierzesz dostawcę zarządzanego.