Authentik vs ZITADEL vs Keycloak: které self-hosted SSO si vybrat?

Na VPS vám běží osm Docker kontejnerů. Gitea, Nextcloud, Grafana, Vaultwarden, n8n, Portainer, stavová stránka a jedna interní aplikace, kterou jste napsali sami. Každý má vlastní přihlášení. Každé ráno kopírujete hesla ze správce hesel a začínáte přemýšlet, jestli jednotné přihlášení stojí za provozní náklady.

Obvykle stojí. Otázka zní, kterého poskytovatele identity provozovat.

Keycloak je známá výchozí volba, ale lepší volba závisí na tom, jak vypadá váš stack, kolik uživatelů spravujete a jestli integrujete software, který už provozujete, nebo stavíte autentizaci do vlastních aplikací.

Toto srovnání self-hosted SSO se dívá na Authentik, ZITADEL, Keycloak a Authelia optikou rozhodnutí, na kterých po nasazení záleží: podpora protokolů, správa uživatelů, vývojářský workflow, nároky na zdroje a co se stane, když poskytovatel identity vypadne.

Proč na self-hosted SSO záleží

Jakmile několik aplikací závisí na stejných lidech a skupinách, oddělená přihlášení přestanou být pohodlná. Self-hosted poskytovatel identity vám dá jedno místo pro správu účtů, MFA, členství ve skupinách a přístupových politik místo toho, abyste tyto kontroly nastavovali zvlášť v každé aplikaci.

Druhá strana mince je stejně důležitá: IdP se stane infrastrukturou, na které závisí ostatní aplikace. Když je nedostupný, mohou selhávat nová přihlášení i obnovy tokenů, takže zálohy, nouzový přístup, aktualizace a dostupnost tu znamenají víc než u běžné self-hosted aplikace.

Stručně

Zvolte Authentik, pokud chcete nejlepší výchozí volbu

Pro homelab, stack interních nástrojů nebo malý tým, který připojuje existující aplikace přes OIDC nebo SAML, je Authentik nejsilnější výchozí volbou. Jeho administrační workflow se dá zvládnout snáz než u Keycloaku, podporuje několik způsobů integrace a jeho oficiální nastavení Docker Compose začíná na 2 jádrech CPU a 2 GB RAM.

Zvolte ZITADEL, pokud stavíte aplikace

Zvolte ZITADEL, když je autentizace součástí produktu, který stavíte. Jeho model organizací, API, multitenance, OIDC, SAML, passkeys, MFA a podpora LDAP poskytovatelů identity dávají větší smysl týmům SaaS a B2B aplikací než typickému homelabu.

Zvolte Keycloak, pokud potřebujete podnikové funkce identity

Zvolte Keycloak, když potřebujete hlubší federaci s LDAP nebo Active Directory, více realmů, jemně odstupňované autorizační politiky nebo prostředí už postavené kolem Keycloaku. Dokumentace doporučuje limit paměti 2 GB pro menší produkční kontejnery Keycloak; VPS typu vše v jednom, na kterém běží i PostgreSQL, potřebuje rezervu navíc.

Alternativa: zvolte Authelia, pokud potřebujete hlavně přihlašovací bránu

Zvolte Authelia, když je vaším hlavním problémem ochrana aplikací na vrstvě reverzní proxy, a ne provoz plnohodnotné platformy identity. Umí fungovat i jako poskytovatel OpenID Connect, ale autentizace na reverzní proxy zůstává jejím těžištěm.

Co zkontrolovat před výběrem SSO nástroje

Než začnete porovnávat funkce, porovnejte každý nástroj s aplikacemi, protokoly a zdroji identity, které už musíte podporovat.

Kolik aplikací potřebuje SSO?

Začněte u aplikací, ne u poskytovatele identity. Stack se šesti aplikacemi, které už podporují OIDC nebo SAML, je jiný problém než stack starých interních nástrojů, které o žádném z protokolů nic nevědí. První případ ukazuje na plnohodnotný IdP. Druhý může potřebovat autentizaci na vrstvě reverzní proxy.

Podporují vaše aplikace OIDC nebo SAML?

OIDC je běžná volba pro moderní webové aplikace. SAML stále hraje roli v podnikovém softwaru a starších integracích. LDAP může být důležitý, když aplikace očekává adresář místo webového SSO toku. Ověřte, co každá aplikace skutečně přijímá, než vyberete IdP, který bude stát uprostřed.

Spravujete uživatele, nebo stavíte přihlášení do aplikace?

Pokud většina vaší práce proběhne v administračním rozhraní při připojování existujících aplikací, je Authentik přirozeným výchozím bodem. Pokud je autentizace součástí produktu, který stavíte, a počítáte se zakládáním organizací, uživatelů a oprávnění kódem, je ZITADEL tomuto workflow mnohem blíž.

Potřebujete LDAP, Active Directory nebo pokročilé politiky?

Authentik, ZITADEL i Keycloak se umí v nějaké podobě připojit ke zdrojům identity postaveným na LDAP, takže samotný LDAP už srovnání nerozhoduje. Keycloak začne být zajímavější, když se federace adresáře kombinuje s více realmy, podrobnými mappery, požadavky na synchronizaci nebo autorizačními politikami na úrovni zdrojů.

Authentik vs ZITADEL vs Keycloak vs Authelia

Čtyři nástroje se v SSO překrývají, ale k identitě přistupují z různých směrů: integrace aplikací, produktová identita, podnikový IAM a přístup přes reverzní proxy.

Authentik

Authentik provozuje své základní nasazení jako server, worker a databázi PostgreSQL. Redis už není součástí stacku: Authentik tuto závislost ve vydání 2025.10 zcela odstranil. Aktuální dokumentace k Docker Compose vyžaduje hostitele s alespoň 2 jádry CPU a 2 GB RAM.

Určujícím rysem je administrační rozhraní. Engine toků v Authentiku, provisioning aplikací a skupinové politiky se zvládají snáz než širší konfigurační model Keycloaku. Pokud jste někdy nastavovali OIDC aplikaci v Keycloaku a pak zjišťovali, proč vám v tokenu chybí claims, rozdíl poznáte rychle.

Podporuje SAML, OAuth2/OIDC, LDAP a RADIUS. Je to správná výchozí volba pro homelab nebo malý inženýrský tým provozující stack self-hosted aplikací.

ZITADEL

ZITADEL je napsaný převážně v Go, licencovaný pod AGPL-3.0 a nachází se na vydávací řadě v4.x. Nasazení zahrnuje API v Go, přihlašovací rozhraní v Next.js a PostgreSQL a aktuální požadavky podporují PostgreSQL 14 až 18. Oficiální dokumentace k Docker Compose vyžaduje hostitele s alespoň 2 GB RAM.

Určujícím rysem je API. ZITADEL vystavuje kompletní identitní rozhraní přes gRPC a REST a od začátku stojí na multitenantním modelu. Pokud stavíte SaaS produkt a chcete, aby přihlašovací vrstva byla programovatelná, automatizovatelná a ve výchozím stavu multitenantní, je ZITADEL blíž tomu, co chcete, než alternativy.

Podporuje OIDC, SAML, passkeys, MFA, LDAP poskytovatele identity a rozhraní SCIM v2, které je aktuálně označené jako Preview. Jeho model organizací a API-first workflow z něj dělají lepší volbu pro produktové týmy než pro jednoduchý homelab.

Keycloak

Keycloak je javová platforma pro správu identit a přístupu běžící na Quarkusu. Má větší konfigurační plochu než ostatní zdejší možnosti, zvlášť jakmile do hry vstoupí Realms, Clients, Roles, federace uživatelů a Authorization Services.

Jeho oficiální dokumentace ke kontejnerům doporučuje limit paměti 2 GB pro menší produkční nasazení. Toto číslo pokrývá samotný kontejner Keycloak; pokud PostgreSQL sdílí stejný VPS, dejte hostiteli větší rezervu.

Důvod, proč tu složitost přijmout, je konkrétní. Keycloak umí federovat adresáře LDAP a Active Directory, zaznamenávat události uživatelů a administrátorů a vynucovat jemně odstupňovanou autorizaci pomocí politik RBAC, ABAC, uživatelských, kontextových a dalších typů. Pokud tyto kontroly potřebujete, má konfigurace navíc svůj účel.

Authelia

Authelia je ze všech čtyř nejmenší: licence Apache 2.0, jediná binárka v Go, aktuálně ve verzi v4.39.x. Architektura se od ostatních tří liší: Authelia stojí před reverzní proxy (nginx, Traefik, Caddy, HAProxy) a rozhoduje, jestli smí požadavky dorazit k backendu.

Authelia obsahuje i poskytovatele OpenID Connect. Její dokumentace stále popisuje implementaci OIDC jako otevřenou betu, ale poskytovatel má certifikaci OpenID pro profily Basic OP, Implicit OP, Hybrid OP, Form Post OP a Config OP. Její sada funkcí OIDC je užší než to, co pro správu identit nabízí Authentik nebo Keycloak, a proto dává Authelia stále největší smysl tam, kde je hlavní prací autentizace na reverzní proxy.

K Authelii se vrátíme ve vlastní sekci. Ve zkratce: těžištěm Authelie je hlídání přístupu na reverzní proxy, ne plnohodnotná správa identit.

Srovnání funkcí

Tabulka níže omezuje srovnání na rozdíly, které ovlivňují nasazení a každodenní správu.

Který nástroj se hodí ke kterému stacku?

Nejlepší volba se mění podle toho, kdo IdP provozuje a jak se s ním aplikace integrují.

Nejlepší volba pro homelab

Authentik je výchozí volbou pro homelab, kde většina aplikací už podporuje OIDC nebo SAML. Dá vám plnohodnotného poskytovatele identity, aniž byste museli přijmout širší IAM model Keycloaku. Pokud většina stacku potřebuje přihlašovací obrazovku na reverzní proxy místo nativního SSO, může být Authelia jednodušší volbou.

Nejlepší volba pro stack malé firmy

Authentik se hodí pro většinu malých stacků interních aplikací, zvlášť když je cílem jedna vrstva identity pro nástroje jako Grafana, Gitea, Nextcloud a Vaultwarden. Keycloak začne být lákavější, když jsou součástí požadavků existující adresář, více realmů nebo hlubší autorizační politiky.

Nejlepší volba pro vývojáře a SaaS produkty

ZITADEL je nejlepší volbou, když je autentizace součástí produktu, který stavíte. Jeho model organizací, multitenance, API a možnosti automatizace dávají větší smysl, když je třeba uživatele a tenanty zakládat z kódu aplikace, a ne primárně přes administrační panel.

ČTĚTE

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

Nejlepší volba pro podnikové týmy nebo týmy s vysokými nároky na compliance

Keycloak dává smysl, když seznam požadavků zahrnuje složitou federaci adresářů, více realmů, podrobné autorizační politiky a tým, který zvládne provozovat složitost IAM navíc. Self-hosting Keycloaku sám o sobě prostředí nezajistí soulad s předpisy; zálohy, dostupnost, logování, revize přístupů a řízení změn zůstávají na vašem týmu.

Nejlepší volba pro aplikace bez nativního SSO

Authelia je nejjasnější volbou, když musí autentizace proběhnout dřív, než požadavky dorazí k aplikaci. Funguje obzvlášť dobře s reverzními proxy, které chrání starší interní nástroje, dashboardy a služby, jež samy OIDC ani SAML nepodporují.

Těžká část self-hostingu SSO

Jakmile je SSO povinné, může chyba v konfiguraci nebo nezdařená obnova zasáhnout několik aplikací najednou.

Instalace a konfigurace

Rozběhnout kontejnery je jen první krok. DNS, TLS, přesměrovací URI, claims v tokenech, mapování skupin, doručování e-mailů a nouzový přístup jsou místa, kde se nasazení SSO začíná měnit v infrastrukturu místo další Docker aplikace.

Serverové zdroje

IdP je jen část rozpočtu na zdroje. PostgreSQL, reverzní proxy, workery, hashování hesel, logy a synchronizace adresářů mohou všechny soupeřit o CPU a paměť, když sdílejí jeden VPS.

Správa databáze a záloh

Authentik, ZITADEL i běžná produkční nasazení Keycloaku závisí na databázi. Zálohujte tuto databázi mimo server, zdokumentujte postup obnovy a obnovu otestujte. Úspěšná zálohovací úloha není totéž co funkční postup obnovy.

Rizika zamknutí a obnovy

Špatná přesměrovací URI, prošlý klientský secret, přerušené spojení s adresářem nebo příliš přísná politika mohou zamknout administrátory spolu se všemi ostatními. Udržujte nouzovou cestu, která nezávisí na autentizačním toku, jenž se snažíte opravit.

Udržení IdP v dostupném stavu

Výpadek IdP nemusí okamžitě ukončit každou existující relaci aplikace. Běžící relace mohou pokračovat, dokud nevyprší jejich vlastní tokeny nebo cookies, ale nová přihlášení a obnovy tokenů mohou selhat. Otestujte tento režim selhání, než SSO v celém stacku zavedete jako povinné.

Kdy byste SSO neměli self-hostovat

Self-hosting přestane být dobrým obchodem, když váš tým nedokáže vrstvu identity obnovovat a provozovat se spolehlivostí, kterou vaše aplikace vyžadují.

Kdy je spravovaná identita bezpečnější

Spravovaná identita stojí za peníze, když jsou náklady na provoz IdP vyšší než kontrola, kterou self-hostingem získáte. Služby jako Auth0, Clerk, WorkOS a Microsoft Entra ID přenášejí velkou část dostupnosti platformy, záplatování a údržby infrastruktury na poskytovatele.

Konfigurace aplikací, oprávnění a plánování obnovy zůstávají na vás, ale už nezodpovídáte za to, aby samotná platforma identity byla online.

Kdy váš tým nezvládne výpadek

Pokud nikdo v týmu nedokáže během výpadku obnovit IdP, opravit PostgreSQL, vyměnit prošlý secret nebo diagnostikovat nefunkční federační spojení, může být self-hosting identity špatným provozním kompromisem.

Selhání je širší než jedna nedostupná aplikace. Nová přihlášení a obnovy tokenů napříč několika aplikacemi mohou selhat současně.

Kdy jsou nároky na compliance příliš vysoké

Self-hosted identitu lze používat v regulovaných prostředích, ale provozování softwaru vlastními silami automaticky nevytvoří kontroly ani důkazy, které auditor očekává. Váš tým dál zodpovídá za logování, revize přístupů, zálohy, řízení změn, dostupnost, reakci na incidenty a veškerou dokumentaci, kterou příslušný rámec vyžaduje.

Self-hosted SSO není symbol prestiže. Pokud váš tým nedokáže vrstvu identity bezpečně provozovat, může být placení za spravovanou identitu lepším inženýrským rozhodnutím.

Kde pomáhá Cloudzy

Cloudzy mění vrstvu nasazení; neodstraňuje práci s konfigurací identity a provozem popsanou výše.

Problém ručního nasazení SSO

Ruční nasazení SSO znamená připravit server, nainstalovat aplikaci a databázi, nakonfigurovat reverzní proxy, nastavit DNS a TLS a teprve potom začít se samotnou konfigurací identity. Nic z toho nenahradí práci s OIDC, SAML, adresářem nebo politikami, která přijde potom.

Nasazení SSO na jedno kliknutí na Cloudzy

Cloudzy nabízí nasazení na jedno kliknutí pro Authentik a Keycloak. Aplikace Authentik na jedno kliknutí je v marketplace Cloudzy. Aplikace Keycloak na jedno kliknutí je v marketplace Cloudzy také. ZITADEL dnes v marketplace není, takže ho nasaďte pomocí jeho nastavení Docker Compose na standardním VPS. Instalace na jedno kliknutí rozběhne základní aplikaci, zatímco konfigurace identity, DNS, zálohy, aktualizace, politiky a testování obnovy zůstávají pod vaší kontrolou.

Kdy použít pro IdP samostatný VPS

Provozovat IdP společně s aplikacemi je rozumné pro homelab, kde je výpadek přijatelný. Pro stack kritický pro byznys odstraní oddělení poskytovatele identity zjevnou sdílenou doménu selhání: restart, vyčerpání zdrojů nebo kompromitace aplikačního serveru už s sebou nestrhne vrstvu identity.

Samostatný VPS není totéž co vysoká dostupnost, ale dá IdP vlastní rozpočet zdrojů, vlastní plán údržby a vlastní hranici obnovy.

Doporučení pro dimenzování VPS

Dimenzujte celý stack, ne jen proces IdP, zvlášť když PostgreSQL a reverzní proxy sdílejí stejný VPS.

Požadavky Authentiku na VPS

Oficiální dokumentace Authentiku k Docker Compose vyžaduje hostitele s alespoň 2 jádry CPU a 2 GB RAM. To je správný výchozí bod pro malé nasazení. Dejte serveru větší rezervu, když stejného hostitele sdílí PostgreSQL, další outposty, synchronizace adresářů nebo silnější přihlašovací provoz.

Požadavky ZITADELu na VPS

Oficiální nasazení ZITADELu přes Docker Compose vyžaduje pro hostitele alespoň 2 GB RAM. Dimenzujte VPS typu vše v jednom pro ZITADEL, jeho přihlašovací rozhraní, PostgreSQL a reverzní proxy dohromady, místo abyste službu v Go posuzovali izolovaně.

Požadavky Keycloaku na VPS

Dokumentace Keycloaku ke kontejnerům doporučuje limit paměti 2 GB pro menší produkční nasazení Keycloaku. Toto číslo platí pro samotný kontejner Keycloak, ne pro celý VPS, na kterém běží i PostgreSQL.

Pokud Keycloak a PostgreSQL sdílejí jeden VPS, jsou 4 GB systémové RAM rozumným výchozím bodem. Berte to jako praktické doporučení pro hostitele, ne jako oficiální minimum Keycloaku.

Požadavky Authelie na VPS

Authelia nezveřejňuje přímo srovnatelné serverové minimum 1 GB nebo 2 GB. Dimenzujte hostitele pro Authelii společně s reverzní proxy, úložným backendem, adresářem uživatelů a všemi dalšími službami sdílejícími stroj.

Authelia má obvykle menší nasazovací stopu než plnohodnotný IdP vedle PostgreSQL, ale skutečné požadavky na VPS závisí na zbytku stacku.

Příklad nastavení: Authentik s Vaultwardenem

Vaultwarden přidal nativní podporu SSO přes OpenID Connect ve verzi 1.35.0 v prosinci 2025. Authentik je užitečný příklad, protože integrace ukazuje ty části OIDC, na které narazíte i u dalších aplikací: přesměrovací URI, klientské přihlašovací údaje, scopes, URL vydavatele a nouzový přístup.

Základní nastavení Authentiku

V Authentiku:

1. Vytvořte vlastní mapování e-mailového scope pro Vaultwarden. Vaultwarden vyžaduje, aby scope email vracel buď email_verified: true, nebo žádnou hodnotu email_verified, zatímco výchozí e-mailový scope Authentiku aktuálně vrací false.
2. Vytvořte dvojici aplikace a poskytovatele OAuth2/OpenID Connect.
3. Přidejte https://vault.example.com/identity/connect/oidc-signin jako striktní přesměrovací URI typu Authorization.
4. Vyberte libovolný dostupný podpisový klíč.
5. Poznamenejte si Client ID, Client Secret a slug aplikace.
6. Nastavte platnost přístupového tokenu na více než pět minut.
7. Přidejte mapování offline_access z Authentiku k vybraným scopes.
8. Nahraďte výchozí e-mailové mapování vlastním mapováním ověřeného e-mailu z kroku 1.

Základní nastavení OIDC ve Vaultwardenu

Použijte:

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

Nahraďte ukázkové domény, slug aplikace, ID klienta a klientský secret hodnotami z vlastního nasazení a pak Vaultwarden restartujte.

ČTĚTE

Self-host Bitwarden password manager: Kompletní návod

Co otestovat před vynucením SSO

Nechte SSO_ONLY nastavené na false, dokud testujete přihlášení, odhlášení, obnovu tokenů, párování účtů a obnovu. Otestujte také, co se stane, když je Authentik dočasně nedostupný.

Jakmile SSO i obnova fungují podle očekávání, můžete se rozhodnout, jestli má vyžadování SSO pro každé přihlášení ve vašem nasazení smysl.

Stejné koncepty OIDC platí i pro další self-hosted aplikace, ale přesměrovací URI, scopes, claims a licence se liší. Řiďte se SSO dokumentací každé aplikace, místo abyste konfiguraci Vaultwardenu kopírovali napřímo.

Kdy je Authelia lepší než plnohodnotný IdP

Authelia začne být lákavější, když aplikace poskytovateli identity vůbec nemusí rozumět.

Autentizace na reverzní proxy

Authelia je navržená hlavně k ochraně aplikací na vrstvě reverzní proxy. Definujete pravidla řízení přístupu a Authelia rozhodne, jestli má požadavek dorazit k backendu, ještě než se autentizací zabývá samotná aplikace.

Ochrana aplikací bez OIDC

To se hodí pro starší interní nástroje, dashboardy a služby, které OIDC ani SAML nepodporují. Místo úprav každé aplikace můžete autentizaci předřadit před ni na reverzní proxy.

Authelia umí fungovat i jako poskytovatel OIDC, ale autentizace na reverzní proxy zůstává její hlavní silou.

Použití Authelie společně s Authentikem

Authentik můžete použít pro aplikace, které podporují OIDC nebo SAML, a Authelii pro aplikace, které potřebují autentizaci na reverzní proxy.

Nutně nepotřebujete oba. Authentik také podporuje ochranu aplikací přes proxy, takže nasazení Authelie vedle něj dává smysl jen tehdy, když její workflow na reverzní proxy řeší konkrétní část vašeho stacku čistěji.

Časté dotazy

Je Authentik lepší než Keycloak?

Pro většinu homelabů a malých stacků self-hosted aplikací se Authentik zvládá snáz. Jeho administrační workflow se soustředí na aplikace, poskytovatele, skupiny a politiky, aniž by najednou vystavoval tolik složitosti IAM.

Keycloak dává větší smysl, když potřebujete konkrétně jeho hlubší federaci, model realmů nebo Authorization Services. Authentik je silnější výchozí volbou pro jednodušší self-hosted SSO; Keycloak se hodí do prostředí, která potřebují tyto kontroly navíc.

Je ZITADEL lepší než Keycloak?

ZITADEL se hodí lépe, když stavíte produkt a chcete identitu řízenou přes API, organizace a multitenanci. Keycloak se hodí lépe, když potřebujete jeho hlubší autorizační model, rozsáhlé federační kontroly nebo prostředí už postavené kolem Keycloaku.

Jaký je rozdíl mezi Authentikem a Authelií?

Authentik je plnohodnotný poskytovatel identity postavený kolem uživatelů, skupin, aplikací, poskytovatelů, toků a politik. Aplikace se s ním mohou integrovat přímo přes protokoly jako OIDC a SAML.

Authelia se soustředí na autentizaci a řízení přístupu na reverzní proxy. Obsahuje i poskytovatele OIDC, ale ochrana na reverzní proxy zůstává jejím hlavním případem použití.

Zvolte Authentik, když se aplikace integrují přímo s IdP. Zvolte Authelii, když musí autentizace proběhnout hlavně dřív, než provoz dorazí k aplikaci.

Můžu provozovat Authentik na VPS s 1 GB?

Ne jako podporovaný výchozí bod. Aktuální dokumentace Authentiku k Docker Compose vyžaduje alespoň 2 jádra CPU a 2 GB RAM. Aktuální základní nasazení používá server Authentik, worker a PostgreSQL; Redis byl v Authentiku 2025.10 zcela odstraněn.

Berte 2 GB jako minimální výchozí bod pro malou instalaci a přidejte rezervu, když stroj sdílejí další služby.

Podporuje Vaultwarden SSO přes OIDC?

Ano. Vaultwarden přidal podporu SSO přes OpenID Connect ve verzi 1.35.0 v prosinci 2025. Vyžaduje externího poskytovatele OIDC, jako je Authentik, Keycloak nebo ZITADEL.

Přesná konfigurace závisí na poskytovateli. U aktuálních vydání Authentiku zdokumentovaná integrace zahrnuje vlastní mapování scope ověřeného e-mailu, offline_access, klientské přihlašovací údaje a URL vydavatele aplikace v Authentiku.

Mám provozovat IdP na stejném VPS jako aplikace?

Pro homelab, kde je výpadek přijatelný, může být společný provoz rozumný. Pro aplikace kritické pro byznys dá samostatný VPS poskytovateli identity vlastní rozpočet zdrojů a vyjme aplikační server ze sdílené domény selhání.

Samo o sobě to vysokou dostupnost nevytvoří, ale restart aplikačního serveru, problém se zdroji nebo kompromitace už automaticky nestrhne IdP s sebou.

Které self-hosted SSO se používá nejsnáz?

Authentik je nejsnazším výchozím bodem pro většinu lidí, kteří připojují existující self-hosted aplikace. Jeho administrační rozhraní dělá aplikace, poskytovatele, skupiny a politiky přístupnějšími než širší model realmů a autorizace v Keycloaku.

Authelia může být jednodušší, když potřebujete jen autentizaci na reverzní proxy. ZITADEL dává větší smysl, když identitu konfiguruje vývojář pracující primárně přes API.