Nejlepší vlastní hostovaný CIAM pro tvůrce B2B SaaS

Pokud jste se podívali na ceníky některých CIAM platforem v SaaS, nejspíš jste si všimli, jak drahé dokážou být, a s velkou pravděpodobností jste zvažovali vlastní hostování.

Tento článek je o čtyřech vlastních hostovaných CIAM platformách, které malý B2B SaaS tým skutečně zvládne provozovat, aniž by se z toho stal druhý úvazek na plný úvazek: ZITADEL, FusionAuth, Logto a Ory Hydra. Nemají všechny stejný tvar a ta správná pro vás závisí méně na seznamu funkcí a více na tom, jaký B2B produkt stavíte. Týden jsem je provozoval vedle sebe na jednom VPS, abych připravil toto srovnání, a následuje verze, kterou bych poslal zakladateli, který mi napíše ohledně CIAM.

Hned na úvod: řeč je o CIAM jako o funkci produktu, ne o interním SSO pro váš vlastní tým.

Zkrácená verze

Čtyři vlastní hostované CIAM platformy, každá na jeden řádek:

• ZITADEL pokud chcete multi-tenancy a B2B organizace rovnou z krabice.
• FusionAuth pokud chcete vypiplané administrátorské rozhraní a dlouhou, předvídatelnou historii vydání.
• Logto pokud chcete nejčistší vývojářský zážitek hned první den.
• Ory Hydra pokud stavíte na úrovni protokolu a chcete OAuth 2.0 engine, ne hotovou přihlašovací aplikaci.

Ve zkratce: ZITADEL je nejbezpečnější první sázka pro typický B2B SaaS a zbytek článku toto zdůvodnění rozebírá.

Proč je CIAM jiné rozhodnutí než firemní SSO

Když vypadne SSO pro váš interní tým, škody bývají omezené. Vaši inženýři možná na hodinu ztratí přístup ke Grafaně nebo jinému internímu nástroji. Když vypadne CIAM, vaši platící zákazníci se do produktu nepřihlásí vůbec. Tím se otázka posouvá od „který autentizační nástroj se našemu týmu hodí?“ k „kterému autentizačnímu systému můžeme věřit jako součásti samotného produktu?“

CIAM, tedy druh identitní infrastruktury, jaký B2B SaaS potřebuje, vyžaduje také primitiva, která mnoho nástrojů pro firemní SSO nezdůrazňuje. Váš zákazník není jeden uživatel, ale organizace (tenant) s vlastními uživateli, rolemi, brandingem a případně vlastním SAML propojením na firemní IdP. Neověřujete jen lidi, ale izolujete uživatele jedné firmy od uživatelů jiné uvnitř téhož produktu. Právě na tuto B2B podobu míří čtyři nástroje níže, každý po svém. Keycloak už má plnohodnotné Organizations, takže odmítat jej jako nástroj jen pro zaměstnance by bylo zastaralé; jeho vynechání vysvětluji v FAQ.

Trojúhelník postavit / koupit / hostovat si sám tu vypadá také jinak. Psát OAuth od nuly je zbytečná chyba. Dodáváte SaaS produkt, ne poskytovatele identity. Koupit spravovanou službu (Auth0, Clerk, WorkOS) je správná volba, když má tým nulovou kapacitu na provoz a rozumný rozpočet. Dvoučlennému startupu bych nikdy neradil hostovat autentizaci vlastními silami hned první den. Vlastní hostování začne dávat smysl, jakmile cena za MAU u spravovaného CIAM překročí náklady na infrastrukturu plus průběžný čas inženýrů, nebo když potřebujete přímou kontrolu nad nasazením a datovou rovinou. V týmech, se kterými jsem pracoval, tenhle bod obvykle nastane někde mezi „máme skutečný produkt“ a „máme skutečné oddělení customer success“.

Pokud hledáte SSO pro vlastní aplikace, a ne pro aplikace svých zákazníků, je to jiné srovnání než tohle. Pojďme na naše favority.

Čtyři nástroje, jeden po druhém

Vybral jsem tyhle čtyři, protože mají dost CIAM tvar na to, aby se daly hodnotit jako produktová infrastruktura, ne jen jako interní SSO. ZITADEL, FusionAuth, Logto i Ory nabízejí skutečnou cestu k vlastnímu hostování a dost tahu na to, aby se braly vážně. Varianty, které jsou jen knihovna, ty zaměřené na firemní SSO a méně vyzrálé možnosti patří spíš do FAQ.

ZITADEL

ZITADEL je identitní platforma švýcarského původu napsaná v Go, s event-sourced architekturou a PostgreSQL backendem. K 27. červenci 2026 je jejím nejnovějším vydáním na GitHubu the 4.16 series, current as of July 2026. ZITADEL přešel od verze v3 z Apache 2.0 na AGPL-3.0; při běžném SaaS použití bývá praktický dopad méně děsivý, než zní, a detaily rozebírám v FAQ.

Čím ZITADEL vyniká pro B2B SaaS: organizace a multi-tenancy jsou plnohodnotná primitiva, ne funkce, které si poskládáte z obecných objektů. Vytvoříte Organization, ta dostane vlastní uživatele, politiky, branding a nastavení přístupu, a můžete jí udělit projekty, aby si její administrátoři spravovali přiřazování rolí pro vlastní uživatele. Nemusíte nad obecnými uživateli vymýšlet pojem „tenant“. Začínáte s ním.

Vývojářská zkušenost je API-first: aktuální zdrojová REST API v2 plus gRPC a REST přístup ke starším službám v1. Oficiální i komunitní SDK pokrývají běžné serverové stacky. Administrátorská konzole je funkční, ale střídmější než u FusionAuth.

Můj pohled: Pokud stavíte B2B SaaS a víte, že budete mít tenanty, začal bych se ZITADEL. Z vlastních hostovaných variant je to ta, která je nejzřetelněji tvarovaná kolem problému B2B přihlašování.

FusionAuth

FusionAuth je americká platforma od Inversoft, LLC (delawarská LLC podnikající pod značkou FusionAuth), která je na trhu déle než zbylé tři, a je to znát, v dobrém. Administrátorské rozhraní působí výrazně promyšleněji než u ostatních, dokumentace je vyzrálá a tempo vydávání je spíš vyrovnané než překotné. Pokud jste někdy zdědili čtyři roky starou integraci autentizace a v duchu poděkovali předchozímu inženýrovi, že zvolil nudnou variantu, FusionAuth je ta podoba CIAM, která si takové poděkování zaslouží.

Kámen úrazu je licencování: FusionAuth Community si můžete hostovat zdarma, ale jádro produktu není open source. Produkt se řídí vlastní licencí FusionAuth, a tyto limity mají význam, pokud plánujete FusionAuth přeprodávat, vkládat, přeznačkovat, dále distribuovat nebo hostovat pro vlastní zákazníky. Vlastní hostovaná verze Community pokrývá základní B2B SaaS scénář; placené plány přidávají funkce jako SAML iniciovaný ze strany IdP, pokročilé MFA a témata specifická pro aplikaci, zatímco SCIM, Tenant Manager a MFA politiky na úrovni aplikace jsou v Enterprise.

K B2B podobě: FusionAuth modeluje tenanty a aplikace, ale abstrakce je spíš „kontejnerizovaná autentizace na tenanta“ než „B2B organizace jako doménový objekt“. Funguje to (vydal jsem na tom produkty), ale multi-tenancy působí spíš jako izolační primitivum než jako plnohodnotný B2B model. Oficiální SDK a klientské knihovny jsou široké:

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

Serverové knihovny jsou tenké API klienty. Administrátorskou konzoli je ve srovnání s ostatními snazší předat provoznímu člověku, který není inženýr.

Můj pohled: Pokud váš tým cení vypiplané rozhraní a dlouhou, předvídatelnou historii víc než nativní B2B primitiva, pak FusionAuth. Je to tady ta nejvíc „nudná“ volba, a to je pochvala.

Logto

Logto je z těchto čtyř nejmladší, vyvíjí jej Silverhand Inc. a je licencovaný pod MPL-2.0, a je to ten, kterému na dashboardu nejviditelněji záleží. Rozjezd první den je poměrně rychlý. Provisionujete, proklikáte průvodce a zhruba za patnáct minut máte funkčního OIDC poskytovatele se slušným výchozím přihlašovacím rozhraním (změřil jsem si to v týdnu, kdy jsem všechny čtyři provozoval vedle sebe). Oficiální quick starty pokrývají moderní frameworky a serverové stacky, takže pokud je váš stack „Next.js + Postgres + něco“, budete jako doma.

Jeho B2B odpověď se jmenuje Logto Organizations. Pokrývá základní B2B primitiva: členství v organizaci, role v rozsahu organizace, pozvánky členů, just-in-time provisioning a integraci firemního SSO. Model organizace je mladší než u ZITADEL, takže bych jakýkoli neobvyklý SAML, SCIM nebo federační tok otestoval s vašimi cílovými zákazníky, než se zavážete.

Kompromisem je vyzrálost: Logto je tu nejnovější varianta. Roadmapa jede rychle, což je skvělé, když přistane funkce, kterou potřebujete, a nepříjemné, když přistane rozbíjející změna. Pokud je váš B2B SaaS na jednodušším konci spektra multi-tenancy (pár organizací a žádné exotické federační požadavky), vývojářská zkušenost Logta zbytek rozhodnutí usnadní.

Můj pohled: Pokud chcete nejrychlejší první den a vaše B2B potřeby jsou zatím poměrně jednoduché, pak Logto.

Ory Hydra (a stack Ory)

Ory Hydra je OAuth 2.0 / OpenID Connect server z ekosystému Ory, licencovaný pod Apache-2.0. Kompletní stack Ory doplňuje Hydru o Ory Kratos (identita a správa uživatelů, samoobslužné přihlášení, registrace, MFA a obnova účtu), Ory Keto (autorizační server ve stylu Zanzibar sloužící jako rozhodovací bod politik) a Ory Oathkeeper (identitní a přístupovou proxy, která ověřuje, autorizuje a upravuje příchozí HTTP požadavky). Poskládáte si, co potřebujete. Všechno je napsané v Go a API jsou čistá.

Háček (a není to vada; pro správný tým je to přednost) je v tom, že Hydra je motor, ne aplikace. Ze své podstaty se Hydra napojuje na oddělenou přihlašovací a souhlasovou aplikaci , kterou dodáte vy. Pokud chcete přihlašovací obrazovku rovnou z krabice, tohle není ten nástroj. Pokud stavíte něco, kde je autentizační tok součástí produktu (vývojářská platforma, na míru dělaný B2B portál nebo API-first produkt s vlastním onboardingem), absence předepsaného UI je přesně to, co chcete.

B2B příběh je skládatelný, ne na klíč. Multi-tenancy si namodelujete napojením Kratos schémat a Keto relací na vlastní organizační vrstvu, a funguje to, jenže to zapojování děláte vy. Cenou je víc instalatérské práce, přínosem kontrola nad zážitkem. Dokumentace Ory pokrývá protokolovou plochu do hloubky, ale skládatelný model předpokládá, že jste ochotni dělat rozhodnutí na úrovni protokolu sami. Pokud vám „audience claim“ nebo „PKCE“ nic neříká, začněte s některým ze zbylých tří.

Můj pohled: Pokud stavíte něco na úrovni protokolu (autentizační bránu, vlastní toky, vývojářskou platformu) a standardní aplikace vás svazují, Ory je správná odpověď. Pro typický B2B SaaS, který chce mít přihlašování funkční dnes, není.

Srovnání na první pohled

Tady je shrnutí čtyř nástrojů v jedné tabulce, hodí se na druhé čtení, není to náhrada profilů výše.

Kterým začít?

Čtyři krátké scénáře, které pokryjí většinu týmů, s nimiž bych to řešil.

Stavíte B2B SaaS a víte, že budete mít tenanty. Začněte se ZITADEL. Primitiva pro multi-tenancy a organizace jsou navržena přesně na tohle, API plocha je kompletní a vymýšlením modelu tenanta strávíte míň času než u kterékoli ze zbylých tří. Přechod na AGPL si zaslouží právní revizi, ale neupravené, samostatně integrované nasazení bývá přímočarý SaaS scénář.

Chcete vypiplané administrátorské rozhraní a stabilní, předvídatelnou platformu. FusionAuth. Plán Community pokryje základní potřeby mnoha týmů; počítejte s časem na pečlivé pročtení licence a matice funkcí. Funkce jako SAML iniciovaný ze strany IdP, pokročilé MFA a témata specifická pro aplikaci vyžadují placený plán, zatímco SCIM, Tenant Manager a MFA politiky na úrovni aplikace jsou v Enterprise.

Vaše B2B potřeby jsou dnes jednoduché a chcete nejrychlejší první den. Logto. Jeho vývojářská zkušenost první den byla v mém srovnávacím testu nejrychlejší. Smiřte se s tím, že sázíte na mladší ekosystém, a rozhodnutí přehodnoťte, pokud vaše požadavky dorostou do federačních hraničních případů, které jste netestovali.

Stavíte něco, kde jsou autentizační toky součástí produktového zážitku. Ory Hydra (plus Kratos, plus Keto, pokud potřebujete oprávnění). Napíšete víc kódu. Budete mít víc kontroly. Pokud vám tenhle obchod není zřejmý, nejste cílová skupina Ory. Vyberte si některý ze zbylých tří.

Pokud vám sedí dva z těchhle popisů, sáhněte defaultně po ZITADEL. Padne nejšířeji a je to ten, který bych malému zakladatelskému týmu dal bez mnoha doplňujících otázek.

Co vás vlastní hostování stojí (provozně)

Tady přichází neromantická část článku.

Vaše disciplína záloh PostgreSQL je teď věc, na které závisí byznys. Napříč těmito nasazeními může identitní stav, který musíte chránit, zahrnovat záznamy uživatelů, hashované přihlašovací údaje, MFA tajemství, přihlašovací údaje OAuth klientů a data relací. Ztraťte tenhle stav a vaši zákazníci můžou přijít o možnost se přihlásit. Nastavte automatické zálohy dřív, než se zaregistruje první opravdový uživatel, otestujte obnovu a zdraví záloh dejte do stejného alertovacího kanálu jako dostupnost aplikace.

Tempo vydávání se v čase mění. ZITADEL v4.16.1 vyšel 17. července 2026 po několika červnových vydáních a každý projekt tady si drží vlastní kadenci a politiku kompatibility. Berte tu kadenci jako téma údržby, ne jako zkratku k posouzení kvality. Než spustíte docker compose pull, přečtěte si poznámky k vydání a naplánujte si opakované okno pro záplaty. Vynechávat aktualizace poskytovatele identity celé měsíce vás při první opravdové kontrole může nechat pozadu za bezpečnostními a kompatibilitními opravami.

Všední věci, které vás vždycky doženou: obnova TLS certifikátů (použijte reverzní proxy s Let's Encrypt, automatizujte obnovy a nastavte alerty na selhání), konfigurace odchozí pošty pro ověřovací e-maily a resety hesel (SES, SendGrid, Postmark: vyberte jednoho a pořádně nastavte SPF/DKIM/DMARC, jinak vám e-maily s resetem skončí ve spamu), rotace OAuth klientských přihlašovacích údajů, když odejde inženýr, a rate limiting přihlašovacích endpointů, aby vám útok typu credential stuffing nevytížil procesor.

Tip: pokud používáte spravovaný Postgres, nepředpokládejte, že běhový databázový uživatel dokáže i založit schéma. Vytvořte databázi a uživatele předem, přidělte potřebná vlastnická nebo instalační oprávnění a první setup spusťte s údaji, které daný nástroj očekává. Jinak vám první běh může spadnout na mlhavé chybě oprávnění k databázi a spálíte hodinu honbou za špatnou stopou.

Co vám cesta vlastního hostování ušetří v dolarech, vezme si na vlastnictví. Po nasazení počítejte s pár inženýrskými hodinami měsíčně na udržení identitní vrstvy ve zdraví. Týmy, které si nevyhradí čas žádný, náklad obvykle objeví později: při výpadku, u divného SAML hraničního případu nebo při první bezpečnostní kontrole.

Kam je nasadit

Linuxový VPS s Docker Compose může být rozumný start pro evaluaci a skromnou zátěž, ale produkční dimenzování a vysoká dostupnost závisí na provozu, bezpečnostních požadavcích a vaší toleranci k výpadkům. Takhle zapadají běžné varianty nasazení:

• Sdílený hosting nespustí ani jeden z nich. Potřebují perzistentní úložiště, vlastní porty, root přístup pro běhové prostředí kontejnerů a skutečný databázový backend. PostgreSQL je pro většinu tohoto seznamu výchozí cesta, ale doslova to není jediná podporovaná databáze u každého nástroje.
• Kubernetes zvládne všechny čtyři, ale oficiální cesta je nevyrovnaná. ZITADEL, FusionAuth, a Ory publikují vlastní Helm charty, zatímco dokumentace vlastního hostování Logto se soustředí na nasazení přes Docker a VM. Pro malý B2B SaaS, který zatím nedospěl do bodu, kdy se Kubernetes vyplatí jinde, je to obvykle přehnané inženýrství. Sáhněte po něm, až tam bude zbytek vaší infrastruktury.
• Bare metal je v pohodě, pokud už na něm jedete. Většina B2B SaaS týmů nejede.

Pro malý pilot na jednom uzlu bych začal na 4 GB RAM, 2 vCPU a 60 GB NVMe úložiště a pak zátěžově otestoval skutečný přihlašovací tok. Je to plánovací základ, ne univerzální produkční minimum. Aplikace jsou poměrně lehké, ale PostgreSQL potřebuje paměť a hashování hesel rezervu CPU. Produkční doporučení ZITADEL doporučují mít k dispozici čtyři jádra CPU pro špičky při hashování hesel.

Až bude produkt skutečný a provoz trvalý, přeškálujte podle měření. Rychlé úložiště pomáhá latenci PostgreSQL, zatímco rezerva CPU se počítá při souběžném hashování hesel. Sledujte paměť, I/O databáze, latenci přihlášení a saturaci CPU místo předpokladu, že jeden zdroj je nejdůležitější.

Provozovat CIAM v produkci znamená, že jeho dostupnost je teď váš problém. My pro takovou zátěž provozujeme instance Cloudzy Linux VPS pro tenhle typ zátěže, s NVMe úložištěm a SLA dostupnosti 99,95 % na základní platformě. Cloudzy nabízí také ZITADEL VPS na jedno kliknutí pokud se chcete vyhnout úvodnímu provisioning skriptu; zbylé tři nabízejí oficiální kontejnerové image pro nasazení přes Docker. Manažerský pohled na to, jak řízení přístupu zapadá do zbytku vaší bezpečnostní pozice, nabízí průvodce osvědčenými postupy IAM průvodce, který to bere z pohledu politik.

Časté dotazy

Ovlivňuje licence AGPL od ZITADEL můj SaaS?

U neupraveného, samostatně integrovaného nasazení obvykle ne, ale tohle není právní poradenství. Povinnosti AGPL u ZITADEL se vztahují na samotný ZITADEL. Pokud ZITADEL upravíte a tu upravenou verzi provozujete jako síťovou službu, licence po vás může chtít nabídnout odpovídající zdrojový kód pod AGPL. Zveřejněný postoj ZITADEL je, že pouhé použití neupravené instance jako identitní služby vašeho SaaS samo o sobě nevyžaduje licencovat vaši oddělenou aplikaci pod AGPL. Přečtěte si oznámení ZITADEL o licencování a poraďte se s právníkem, pokud software upravujete, dále distribuujete, vkládáte nebo nabízíte třetím stranám. K dispozici je i komerční licence.

Proč na tomhle seznamu není Keycloak nebo Authentik?

Keycloak a Authentik jsou vynikající vlastní hostované identitní nástroje (používám je), ale vyřadit Keycloak proto, že mu chybí B2B organizace, by dnes byla chyba: aktuální vydání Keycloaku obsahují Organizations, skupiny organizací i řízení delegované správy. Vynechal jsem ho, protože tohle srovnání se soustředí na čtyři varianty s přímější cestou pro malý B2B SaaS tým; Keycloak si zaslouží vlastní vyhodnocení, když jde o provoz JVM, hloubku ekosystému a flexibilitu na úrovni realmů. Authentik zůstává vhodnější pro firemní a interní aplikační SSO než pro produktově nativní modelování tenantů.

Je vlastní hostování levnější než Auth0?

Při nízkých MAU často ne. Vaše inženýrské hodiny stojí víc než účet od Auth0 na úrovni raného startupu. Vlastní hostování ekonomicky vítězí v měřítku, kdy cena spravovaného CIAM za MAU překročí součet nákladů na malý VPS a těch pár inženýrských hodin měsíčně. Přesný bod zvratu závisí na hodinových nákladech vašeho týmu, na křivce růstu MAU a na tom, jestli produkt potřebuje enterprise funkce, které vás vytlačí do dražších úrovní Auth0. Berte úsporu jako skutečnou, ale ne okamžitou.

Jaká je minimální velikost VPS pro produkční CIAM?

Pro malý pilot na jednom uzlu jsou 4 GB RAM, 2 vCPU a NVMe úložiště rozumný start, ne produkční záruka. Dimenzujte podle velikosti databáze, souběžné přihlašovací zátěže, ceny hashování hesel a cíle dostupnosti. Vlastní produkční doporučení ZITADEL radí mít k dispozici čtyři jádra CPU pro špičky hashování; jiné nástroje a profily provozu si žádají vlastní zátěžové testy.

Můžu později přejít ze spravovaného CIAM na vlastní hostování?

Ano, ale naplánujte to jako opravdový projekt. Resety hesel nejsou nevyhnutelné: exportovatelnost a podporované formáty hashů se liší a některé cíle podporují hromadnou nebo just-in-time migraci uživatelů , zatímco jiné vyžadují reset. MFA faktory, OAuth klienti, aktivní relace, stav ověření e-mailu a mapování tenantů či rolí potřebují zvláštní zacházení. Pokud už teď tušíte, že později přejdete na vlastní hostování, sepište si tato omezení exportu a migrace ještě před výběrem spravovaného poskytovatele.