Authentik vs. ZITADEL vs. Keycloak: Welches selbst gehostete SSO sollten Sie wählen?

Sie haben acht Docker-Container auf einem VPS laufen. Gitea, Nextcloud, Grafana, Vaultwarden, n8n, Portainer, eine Statusseite und eine interne App, die Sie selbst geschrieben haben. Jede hat ihr eigenes Login. Sie kopieren jeden Morgen Passwörter aus Ihrem Passwort-Manager und fragen sich langsam, ob Single Sign-on den Betriebsaufwand wert ist.

Meistens ja. Die Frage ist, welchen Identity Provider Sie betreiben sollen.

Keycloak ist der vertraute Standard, aber die bessere Wahl hängt davon ab, wie Ihr Stack aussieht, wie viele Nutzer Sie verwalten und ob Sie bereits laufende Software anbinden oder Authentifizierung in Ihre eigenen Anwendungen einbauen.

Dieser Vergleich selbst gehosteter SSO-Lösungen betrachtet Authentik, ZITADEL, Keycloak und Authelia anhand der Entscheidungen, die nach dem Deployment zählen: Protokollunterstützung, Nutzerverwaltung, Entwickler-Workflow, Ressourcenbedarf und was passiert, wenn Ihr Identity Provider ausfällt.

Warum selbst gehostetes SSO wichtig ist

Sobald mehrere Anwendungen von denselben Personen und Gruppen abhängen, sind getrennte Logins nicht mehr bequem. Ein selbst gehosteter Identity Provider gibt Ihnen einen zentralen Ort, um Konten, MFA, Gruppenzugehörigkeit und Zugriffsrichtlinien zu verwalten, statt diese Kontrollen in jeder Anwendung einzeln zu konfigurieren.

Der Nachteil wiegt genauso schwer: Der IdP wird zu Infrastruktur, von der andere Anwendungen abhängen. Neue Logins und Token-Erneuerungen können fehlschlagen, wenn er nicht erreichbar ist. Deshalb zählen Backups, Notfallzugang, Upgrades und Verfügbarkeit hier mehr als bei einer gewöhnlichen selbst gehosteten App.

Kurzfassung

Wählen Sie Authentik, wenn Sie die beste Standardoption wollen

Für ein Homelab, einen Stack interner Tools oder ein kleines Team, das bestehende Anwendungen über OIDC oder SAML anbindet, ist Authentik der stärkste Standard. Sein Admin-Workflow ist leichter zugänglich als der von Keycloak, es unterstützt mehrere Integrationswege, und sein offizielles Docker-Compose-Setup beginnt bei 2 CPU-Kernen und 2 GB RAM.

Wählen Sie ZITADEL, wenn Sie Anwendungen bauen

Wählen Sie ZITADEL, wenn Authentifizierung Teil des Produkts ist, das Sie bauen. Sein Organisationsmodell, seine APIs, Multi-Tenancy, OIDC, SAML, Passkeys, MFA und die Unterstützung für LDAP-Identity-Provider ergeben für SaaS- und B2B-Anwendungsteams mehr Sinn als für ein typisches Homelab.

Wählen Sie Keycloak, wenn Sie Enterprise-Identity-Funktionen brauchen

Wählen Sie Keycloak, wenn Sie tiefere LDAP- oder Active-Directory-Föderation, mehrere Realms, feingranulare Autorisierungsrichtlinien oder eine bereits um Keycloak herum gebaute Umgebung brauchen. Die Dokumentation empfiehlt ein Speicherlimit von 2 GB für kleinere produktionsreife Keycloak-Container; ein All-in-one-VPS, auf dem zusätzlich PostgreSQL läuft, braucht mehr Spielraum.

Alternative: Wählen Sie Authelia, wenn Sie vor allem eine Login-Sperre brauchen

Wählen Sie Authelia, wenn Ihr Hauptproblem darin besteht, Anwendungen auf der Reverse-Proxy-Ebene zu schützen, statt eine vollständige Identity-Plattform zu betreiben. Es kann auch als OpenID-Connect-Provider arbeiten, aber die Authentifizierung am Reverse Proxy bleibt sein Schwerpunkt.

Was Sie vor der Wahl eines SSO-Tools prüfen sollten

Bevor Sie Funktionen vergleichen, gleichen Sie jedes Tool mit den Anwendungen, Protokollen und Identitätsquellen ab, die Sie bereits unterstützen müssen.

Wie viele Apps brauchen SSO?

Beginnen Sie bei den Anwendungen, nicht beim Identity Provider. Ein Stack mit sechs Anwendungen, die OIDC oder SAML bereits unterstützen, ist ein anderes Problem als ein Stack alter interner Tools, die keines der beiden Protokolle kennen. Der erste Fall spricht für einen vollständigen IdP. Der zweite braucht womöglich Authentifizierung auf der Reverse-Proxy-Ebene.

Unterstützen Ihre Apps OIDC oder SAML?

OIDC ist die übliche Wahl für moderne Webanwendungen. SAML spielt in Unternehmenssoftware und älteren Integrationen weiterhin eine Rolle. LDAP kann wichtig sein, wenn die Anwendung ein Verzeichnis statt eines webbasierten SSO-Flows erwartet. Prüfen Sie, was jede Anwendung tatsächlich akzeptiert, bevor Sie den IdP wählen, der dazwischensitzen wird.

Verwalten Sie Nutzer oder bauen Sie ein Login in eine App ein?

Wenn der Großteil Ihrer Arbeit in einer Admin-Oberfläche stattfindet, während Sie bestehende Anwendungen anbinden, ist Authentik der natürliche Ausgangspunkt. Wenn Authentifizierung Teil eines Produkts ist, das Sie bauen, und Sie Organisationen, Nutzer und Berechtigungen per Code anlegen wollen, liegt ZITADEL deutlich näher an diesem Workflow.

Brauchen Sie LDAP, Active Directory oder erweiterte Richtlinien?

Authentik, ZITADEL und Keycloak können alle in irgendeiner Form an LDAP-gestützte Identitätsquellen angebunden werden, also entscheidet LDAP allein den Vergleich nicht mehr. Keycloak wird interessanter, wenn Verzeichnisföderation mit mehreren Realms, detaillierten Mappern, Synchronisationsanforderungen oder Autorisierungsrichtlinien auf Ressourcenebene zusammenkommt.

Authentik vs. ZITADEL vs. Keycloak vs. Authelia

Die vier Tools überschneiden sich beim SSO, gehen Identität aber aus verschiedenen Richtungen an: Anwendungsintegration, Produktidentität, Enterprise-IAM und Zugriff über den Reverse Proxy.

Authentik

Authentik betreibt sein Kern-Deployment als Server, Worker und PostgreSQL-Datenbank. Redis gehört nicht mehr zum Stack: Authentik hat die Abhängigkeit mit dem Release 2025.10 vollständig entfernt. Die aktuelle Docker-Compose-Dokumentation verlangt einen Host mit mindestens 2 CPU-Kernen und 2 GB RAM.

Das prägende Merkmal ist die Admin-Oberfläche. Authentiks Flow-Engine, die Anwendungsbereitstellung und gruppenbasierte Richtlinien sind leichter zugänglich als Keycloaks breiteres Konfigurationsmodell. Wer schon einmal eine OIDC-Anwendung in Keycloak eingerichtet und dann Zeit damit verbracht hat, herauszufinden, warum Token-Claims fehlten, bemerkt den Unterschied schnell.

Es unterstützt SAML, OAuth2/OIDC, LDAP und RADIUS. Es ist der richtige Standard für ein Homelab oder ein kleines Engineering-Team, das einen Stack selbst gehosteter Apps betreibt.

ZITADEL

ZITADEL ist überwiegend in Go geschrieben, unter AGPL-3.0 lizenziert und befindet sich auf der Release-Linie v4.x. Das Deployment besteht aus einer Go-API, einer Login-Oberfläche in Next.js und PostgreSQL, und die aktuellen Anforderungen unterstützen PostgreSQL 14 bis 18. Die offizielle Docker-Compose-Dokumentation verlangt einen Host mit mindestens 2 GB RAM.

Das prägende Merkmal ist die API. ZITADEL stellt eine vollständige Identitätsoberfläche über gRPC und REST bereit und ist von Anfang an auf ein mandantenfähiges Modell ausgelegt. Wenn Sie ein SaaS-Produkt bauen und die Login-Schicht programmierbar, automatisierbar und standardmäßig mandantenfähig sein soll, kommt ZITADEL dem näher als die Alternativen.

Es unterstützt OIDC, SAML, Passkeys, MFA, LDAP-Identity-Provider und eine SCIM-v2-Schnittstelle, die derzeit als Preview gekennzeichnet ist. Sein Organisationsmodell und sein API-first-Workflow machen es zur besseren Wahl für Produktteams als für ein einfaches Homelab.

Keycloak

Keycloak ist eine Java-Plattform für Identitäts- und Zugriffsverwaltung, die auf Quarkus läuft. Es hat eine größere Konfigurationsoberfläche als die anderen Optionen hier, besonders sobald Realms, Clients, Roles, Nutzerföderation und Authorization Services ins Spiel kommen.

Die offizielle Container-Dokumentation empfiehlt ein Speicherlimit von 2 GB für kleinere produktionsreife Deployments. Dieser Wert gilt für den Keycloak-Container selbst; wenn PostgreSQL denselben VPS teilt, geben Sie dem Host mehr Spielraum.

Der Grund, diese Komplexität in Kauf zu nehmen, ist konkret. Keycloak kann LDAP- und Active-Directory-Verzeichnisse föderieren, Nutzer- und Administrator-Ereignisse aufzeichnen und feingranulare Autorisierung mit RBAC, ABAC, nutzerbasierten, kontextbasierten und weiteren Richtlinientypen durchsetzen. Wenn Sie diese Kontrollen brauchen, hat die zusätzliche Konfiguration einen Zweck.

Authelia

Authelia ist das kleinste der vier: Apache-2.0-lizenziert, eine einzelne Go-Binary, derzeit bei v4.39.x. Die Architektur unterscheidet sich von den anderen drei: Authelia sitzt vor einem Reverse Proxy (nginx, Traefik, Caddy, HAProxy) und entscheidet, ob Anfragen das Backend erreichen dürfen.

Authelia enthält außerdem einen OpenID-Connect-Provider. Die Dokumentation beschreibt die OIDC-Implementierung noch als offene Beta, aber der Provider ist für die Profile Basic OP, Implicit OP, Hybrid OP, Form Post OP und Config OP OpenID-zertifiziert. Sein OIDC-Funktionsumfang ist schmaler als das, was Authentik oder Keycloak für die Identitätsverwaltung bieten, weshalb Authelia weiterhin dann am meisten Sinn ergibt, wenn die Authentifizierung am Reverse Proxy die Hauptaufgabe ist.

Auf Authelia kommen wir in einem eigenen Abschnitt zurück. Kurz gesagt: Authelias Schwerpunkt ist die Zugangskontrolle am Reverse Proxy, nicht die vollständige Identitätsverwaltung.

Funktionsvergleich

Die Tabelle unten beschränkt den Vergleich auf die Unterschiede, die Deployment und tägliche Administration betreffen.

Welches Tool passt zu welchem Stack?

Die beste Wahl hängt davon ab, wer den IdP betreibt und wie die Anwendungen an ihn angebunden sind.

Beste Option für ein Homelab

Authentik ist der Standard für ein Homelab, in dem die meisten Anwendungen bereits OIDC oder SAML unterstützen. Es gibt Ihnen einen vollständigen Identity Provider, ohne dass Sie Keycloaks breiteres IAM-Modell übernehmen müssen. Wenn der Großteil des Stacks eine Login-Maske am Reverse Proxy statt nativem SSO braucht, kann Authelia die einfachere Wahl sein.

Beste Option für den Stack eines kleinen Unternehmens

Authentik passt zu den meisten kleinen internen Anwendungs-Stacks, besonders wenn das Ziel eine einzige Identitätsschicht für Tools wie Grafana, Gitea, Nextcloud und Vaultwarden ist. Keycloak wird attraktiver, wenn ein bestehendes Verzeichnis, mehrere Realms oder tiefere Autorisierungsrichtlinien Teil der Anforderung sind.

Beste Option für Entwickler und SaaS-Produkte

ZITADEL passt am besten, wenn Authentifizierung Teil des Produkts ist, das Sie bauen. Sein Organisationsmodell, Multi-Tenancy, APIs und die Automatisierungsoberfläche ergeben mehr Sinn, wenn Nutzer und Mandanten aus dem Anwendungscode heraus angelegt werden müssen statt hauptsächlich über ein Admin-Panel.

LESEN

Das beste selbst gehostete CIAM für B2B-SaaS-Entwickler

Beste Option für Enterprise- oder compliance-lastige Teams

Keycloak ergibt Sinn, wenn die Anforderungsliste komplexe Verzeichnisföderation, mehrere Realms, detaillierte Autorisierungsrichtlinien und ein Team umfasst, das die zusätzliche IAM-Komplexität betreiben kann. Keycloak selbst zu hosten macht eine Umgebung nicht von allein compliant; Backups, Verfügbarkeit, Protokollierung, Zugriffsüberprüfungen und Änderungskontrollen bleiben Aufgabe Ihres Teams.

Beste Option für Apps ohne natives SSO

Authelia ist die klarste Wahl, wenn die Authentifizierung stattfinden muss, bevor Anfragen die Anwendung erreichen. Es funktioniert besonders gut mit Reverse Proxys, die ältere interne Tools, Dashboards und Dienste schützen, die OIDC oder SAML selbst nicht unterstützen.

Der schwierige Teil beim Selbsthosten von SSO

Sobald SSO verpflichtend ist, kann ein Konfigurationsfehler oder eine fehlgeschlagene Wiederherstellung mehrere Anwendungen auf einmal treffen.

Installation und Konfiguration

Die Container zum Laufen zu bringen ist nur der erste Schritt. DNS, TLS, Redirect-URIs, Token-Claims, Gruppenzuordnungen, E-Mail-Zustellung und Notfallzugang sind die Punkte, an denen ein SSO-Deployment zu Infrastruktur wird statt zu einer weiteren Docker-App.

Serverressourcen

Der IdP ist nur ein Teil des Ressourcenbudgets. PostgreSQL, Reverse Proxys, Worker, Passwort-Hashing, Logs und Verzeichnissynchronisation können alle um CPU und Speicher konkurrieren, wenn sie sich einen VPS teilen.

Datenbank- und Backup-Verwaltung

Authentik, ZITADEL und normale Keycloak-Produktions-Deployments hängen von einer Datenbank ab. Sichern Sie diese Datenbank außerhalb des Servers, dokumentieren Sie die Wiederherstellung und testen Sie sie. Ein erfolgreicher Backup-Job ist nicht dasselbe wie ein funktionierendes Wiederherstellungsverfahren.

Aussperrungs- und Wiederherstellungsrisiken

Eine falsche Redirect-URI, ein abgelaufenes Client-Secret, eine unterbrochene Verzeichnisverbindung oder eine zu strenge Richtlinie kann Administratoren zusammen mit allen anderen aussperren. Halten Sie einen Notfallpfad bereit, der nicht von dem Authentifizierungs-Flow abhängt, den Sie gerade reparieren wollen.

Den IdP verfügbar halten

Ein IdP-Ausfall beendet nicht zwangsläufig sofort jede bestehende Anwendungssitzung. Bestehende Sitzungen können weiterlaufen, bis ihre eigenen Tokens oder Cookies ablaufen, aber neue Logins und Token-Erneuerungen können fehlschlagen. Testen Sie diesen Fehlerfall, bevor Sie SSO im gesamten Stack verpflichtend machen.

Wann Sie SSO nicht selbst hosten sollten

Selbsthosten ist kein guter Deal mehr, wenn Ihr Team die Identitätsschicht nicht mit der Zuverlässigkeit wiederherstellen und betreiben kann, die Ihre Anwendungen verlangen.

Wann verwaltete Identität sicherer ist

Verwaltete Identität ist ihr Geld wert, wenn die Betriebskosten des IdP höher sind als die Kontrolle, die Sie durch Selbsthosten gewinnen. Dienste wie Auth0, Clerk, WorkOS und Microsoft Entra ID verlagern einen großen Teil von Plattformverfügbarkeit, Patching und Infrastrukturwartung zum Anbieter.

Anwendungskonfiguration, Berechtigungen und Wiederherstellungsplanung bleiben bei Ihnen, aber Sie sind nicht mehr dafür verantwortlich, die Identity-Plattform selbst online zu halten.

Wann Ihr Team einen Ausfall nicht verkraften kann

Wenn niemand im Team während eines Ausfalls den IdP wiederherstellen, PostgreSQL reparieren, ein abgelaufenes Secret ersetzen oder eine fehlgeschlagene Föderationsverbindung diagnostizieren kann, ist selbst gehostete Identität womöglich der falsche Betriebs-Trade-off.

Der Ausfall reicht weiter als eine einzelne nicht verfügbare Anwendung. Neue Logins und Token-Erneuerungen über mehrere Anwendungen hinweg können gleichzeitig fehlschlagen.

Wann die Compliance-Anforderungen zu hoch sind

Selbst gehostete Identität lässt sich in regulierten Umgebungen einsetzen, aber die Software selbst zu betreiben erzeugt nicht automatisch die Kontrollen oder Nachweise, die ein Auditor erwartet. Ihr Team bleibt verantwortlich für Protokollierung, Zugriffsüberprüfungen, Backups, Änderungsmanagement, Verfügbarkeit, Incident Response und jede Dokumentation, die das jeweilige Regelwerk verlangt.

Selbst gehostetes SSO ist kein Statussymbol. Wenn Ihr Team die Identitätsschicht nicht sicher betreiben kann, kann es die bessere technische Entscheidung sein, für verwaltete Identität zu zahlen.

Wo Cloudzy hilft

Cloudzy ändert die Deployment-Schicht; es nimmt Ihnen die oben beschriebene Identitätskonfiguration und Betriebsarbeit nicht ab.

Das Problem mit manuellem SSO-Deployment

Ein manuelles SSO-Deployment bedeutet: Server vorbereiten, Anwendung und Datenbank installieren, Reverse Proxy konfigurieren, DNS und TLS einrichten und erst dann mit der eigentlichen Identitätskonfiguration beginnen. Nichts davon ersetzt die OIDC-, SAML-, Verzeichnis- oder Richtlinienarbeit, die danach kommt.

SSO-Deployment mit einem Klick auf Cloudzy

Cloudzy bietet Ein-Klick-Deployments für Authentik und Keycloak. Die Ein-Klick-App für Authentik finden Sie im Cloudzy-Marketplace. Die Ein-Klick-App für Keycloak finden Sie ebenfalls im Cloudzy-Marketplace. ZITADEL ist derzeit nicht im Marketplace; deployen Sie es daher mit seinem Docker-Compose-Setup auf einem normalen VPS. Die Ein-Klick-Installation bringt die Basisanwendung zum Laufen, während Identitätskonfiguration, DNS, Backups, Upgrades, Richtlinien und Wiederherstellungstests unter Ihrer Kontrolle bleiben.

Wann Sie einen separaten VPS für Ihren IdP nutzen sollten

Den IdP zusammen mit Ihren Anwendungen zu hosten ist für ein Homelab vertretbar, in dem Ausfälle akzeptabel sind. Für einen geschäftskritischen Stack beseitigt ein getrennter Identity Provider eine offensichtliche gemeinsame Fehlerdomäne: Den Anwendungsserver neu zu starten, zu überlasten oder zu kompromittieren reißt die Identitätsschicht nicht mehr mit.

Ein separater VPS ist nicht dasselbe wie Hochverfügbarkeit, aber er gibt dem IdP ein eigenes Ressourcenbudget, einen eigenen Wartungsplan und eine eigene Wiederherstellungsgrenze.

Empfehlungen zur VPS-Dimensionierung

Dimensionieren Sie den gesamten Stack, nicht nur den IdP-Prozess, besonders wenn PostgreSQL und ein Reverse Proxy denselben VPS teilen.

VPS-Anforderungen für Authentik

Authentiks offizielle Docker-Compose-Dokumentation verlangt einen Host mit mindestens 2 CPU-Kernen und 2 GB RAM. Das ist der richtige Ausgangspunkt für ein kleines Deployment. Geben Sie dem Server mehr Spielraum, wenn PostgreSQL, zusätzliche Outposts, Verzeichnissynchronisation oder höherer Login-Traffic denselben Host teilen.

VPS-Anforderungen für ZITADEL

ZITADELs offizielles Docker-Compose-Deployment verlangt mindestens 2 GB RAM für den Host. Dimensionieren Sie einen All-in-one-VPS für ZITADEL, seine Login-Oberfläche, PostgreSQL und den Reverse Proxy gemeinsam, statt den Go-Dienst isoliert zu betrachten.

VPS-Anforderungen für Keycloak

Keycloaks Container-Dokumentation empfiehlt ein Speicherlimit von 2 GB für kleinere produktionsreife Keycloak-Deployments. Dieser Wert gilt für den Keycloak-Container selbst, nicht für einen ganzen VPS, auf dem auch PostgreSQL läuft.

Wenn Keycloak und PostgreSQL sich einen VPS teilen, sind 4 GB System-RAM ein vernünftiger Ausgangspunkt. Betrachten Sie das als praktische Host-Empfehlung, nicht als Keycloaks offizielles Minimum.

VPS-Anforderungen für Authelia

Authelia veröffentlicht kein direkt vergleichbares Server-Minimum von 1 GB oder 2 GB. Dimensionieren Sie den Host für Authelia zusammen mit dem Reverse Proxy, dem Speicher-Backend, dem Nutzerverzeichnis und allen anderen Diensten auf derselben Maschine.

Authelia hat in der Regel einen kleineren Deployment-Fußabdruck als ein vollständiger IdP samt PostgreSQL, aber die tatsächlichen VPS-Anforderungen hängen vom Rest des Stacks ab.

Beispiel-Setup: Authentik mit Vaultwarden

Vaultwarden hat in Version 1.35.0 im Dezember 2025 native SSO-Unterstützung über OpenID Connect hinzugefügt. Authentik ist ein nützliches Beispiel, weil die Integration die OIDC-Bausteine zeigt, denen Sie auch bei anderen Anwendungen begegnen: Redirect-URIs, Client-Zugangsdaten, Scopes, Issuer-URLs und Notfallzugang.

Grundlegende Einrichtung in Authentik

In Authentik:

1. Legen Sie ein eigenes E-Mail-Scope-Mapping für Vaultwarden an. Vaultwarden verlangt, dass der Scope email entweder email_verified: true oder gar keinen email_verified-Wert zurückgibt, während Authentiks Standard-E-Mail-Scope derzeit false liefert.
2. Legen Sie ein Paar aus OAuth2/OpenID-Connect-Anwendung und -Provider an.
3. Fügen Sie https://vault.example.com/identity/connect/oidc-signin als strikte Redirect-URI vom Typ Authorization hinzu.
4. Wählen Sie einen beliebigen verfügbaren Signaturschlüssel.
5. Notieren Sie Client ID, Client Secret und den Slug der Anwendung.
6. Setzen Sie die Gültigkeit des Access-Tokens auf mehr als fünf Minuten.
7. Fügen Sie Authentiks offline_access-Mapping zu den ausgewählten Scopes hinzu.
8. Ersetzen Sie das Standard-E-Mail-Mapping durch das eigene Mapping für verifizierte E-Mails aus Schritt 1.

Grundlegende OIDC-Einrichtung in Vaultwarden

Verwenden Sie:

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

Ersetzen Sie die Beispiel-Domains, den Anwendungs-Slug, die Client-ID und das Client-Secret durch die Werte Ihres eigenen Deployments und starten Sie Vaultwarden dann neu.

LESEN

Bitwarden Password Manager selbst hosten: kompletter Guide

Was Sie testen sollten, bevor Sie SSO erzwingen

Lassen Sie SSO_ONLY auf false, während Sie Login, Logout, Token-Erneuerung, Kontozuordnung und Wiederherstellung testen. Testen Sie auch, was passiert, wenn Authentik vorübergehend nicht erreichbar ist.

Sobald SSO und Wiederherstellung wie erwartet funktionieren, können Sie entscheiden, ob es für Ihr Deployment sinnvoll ist, SSO für jedes Login vorzuschreiben.

Dieselben OIDC-Konzepte gelten für andere selbst gehostete Anwendungen, aber Redirect-URIs, Scopes, Claims und Lizenzen unterscheiden sich. Lesen Sie die SSO-Dokumentation jeder Anwendung, statt die Vaultwarden-Konfiguration direkt zu kopieren.

Wann Authelia besser ist als ein vollständiger IdP

Authelia wird attraktiver, wenn die Anwendung den Identity Provider überhaupt nicht verstehen muss.

Authentifizierung am Reverse Proxy

Authelia ist hauptsächlich dafür gebaut, Anwendungen auf der Reverse-Proxy-Ebene zu schützen. Sie definieren Zugriffskontrollregeln, und Authelia entscheidet, ob eine Anfrage das Backend erreichen darf, bevor die Anwendung selbst die Authentifizierung übernimmt.

Apps ohne OIDC schützen

Das ist nützlich für ältere interne Tools, Dashboards und Dienste, die OIDC oder SAML nicht unterstützen. Statt jede Anwendung zu ändern, können Sie die Authentifizierung am Reverse Proxy davorschalten.

Authelia kann auch als OIDC-Provider arbeiten, aber die Authentifizierung am Reverse Proxy bleibt seine größte Stärke.

Authelia zusammen mit Authentik nutzen

Sie können Authentik für Anwendungen nutzen, die OIDC oder SAML unterstützen, und Authelia für Anwendungen, die Authentifizierung am Reverse Proxy brauchen.

Sie brauchen nicht zwangsläufig beides. Authentik unterstützt ebenfalls proxybasierten Anwendungsschutz, daher ergibt Authelia daneben nur Sinn, wenn Authelias Reverse-Proxy-Workflow einen bestimmten Teil Ihres Stacks sauberer löst.

Häufig gestellte Fragen

Ist Authentik besser als Keycloak?

Für die meisten Homelabs und kleinen selbst gehosteten Anwendungs-Stacks ist Authentik leichter zugänglich. Sein Admin-Workflow konzentriert sich auf Anwendungen, Provider, Gruppen und Richtlinien, ohne auf einmal so viel IAM-Komplexität offenzulegen.

Keycloak ergibt mehr Sinn, wenn Sie gezielt seine tiefere Föderation, sein Realm-Modell oder seine Authorization Services brauchen. Authentik ist der stärkere Standard für einfacheres selbst gehostetes SSO; Keycloak passt zu Umgebungen, die diese zusätzlichen Kontrollen brauchen.

Ist ZITADEL besser als Keycloak?

ZITADEL passt besser, wenn Sie ein Produkt bauen und API-gesteuerte Identität, Organisationen und Multi-Tenancy wollen. Keycloak passt besser, wenn Sie sein tieferes Autorisierungsmodell, seine umfangreichen Föderationskontrollen oder eine bereits um Keycloak herum gebaute Umgebung brauchen.

Was ist der Unterschied zwischen Authentik und Authelia?

Authentik ist ein vollständiger Identity Provider, aufgebaut um Nutzer, Gruppen, Anwendungen, Provider, Flows und Richtlinien. Anwendungen können sich direkt über Protokolle wie OIDC und SAML anbinden.

Authelia konzentriert sich auf Authentifizierung und Zugriffskontrolle am Reverse Proxy. Es enthält ebenfalls einen OIDC-Provider, aber der Schutz am Reverse Proxy bleibt sein Hauptanwendungsfall.

Wählen Sie Authentik, wenn Anwendungen direkt an einen IdP angebunden werden. Wählen Sie Authelia, wenn die Authentifizierung hauptsächlich stattfinden muss, bevor der Traffic die Anwendung erreicht.

Kann ich Authentik auf einem VPS mit 1 GB betreiben?

Nicht als unterstützten Ausgangspunkt. Authentiks aktuelle Docker-Compose-Dokumentation verlangt mindestens 2 CPU-Kerne und 2 GB RAM. Das aktuelle Kern-Deployment nutzt den Authentik-Server, den Worker und PostgreSQL; Redis wurde in Authentik 2025.10 vollständig entfernt.

Nehmen Sie 2 GB als minimalen Ausgangspunkt für eine kleine Installation und planen Sie Spielraum ein, wenn andere Dienste die Maschine teilen.

Unterstützt Vaultwarden OIDC-SSO?

Ja. Vaultwarden hat in Version 1.35.0 im Dezember 2025 SSO-Unterstützung über OpenID Connect hinzugefügt. Es braucht einen externen OIDC-Provider wie Authentik, Keycloak oder ZITADEL.

Die genaue Konfiguration hängt vom Provider ab. Mit aktuellen Authentik-Releases umfasst die dokumentierte Integration ein eigenes Mapping für verifizierte E-Mail-Scopes, offline_access, Client-Zugangsdaten und die Issuer-URL der Authentik-Anwendung.

Sollte ich meinen IdP auf demselben VPS wie meine Apps betreiben?

Für ein Homelab, in dem Ausfälle akzeptabel sind, kann gemeinsames Hosting vertretbar sein. Für geschäftskritische Anwendungen gibt ein separater VPS dem Identity Provider ein eigenes Ressourcenbudget und nimmt den Anwendungsserver als gemeinsame Fehlerdomäne heraus.

Das schafft für sich genommen keine Hochverfügbarkeit, aber ein Neustart des Anwendungsservers, ein Ressourcenproblem oder eine Kompromittierung reißt den IdP nicht mehr automatisch mit.

Welches selbst gehostete SSO ist am einfachsten zu bedienen?

Authentik ist für die meisten, die bestehende selbst gehostete Anwendungen anbinden, der einfachste Einstieg. Seine Admin-Oberfläche macht Anwendungen, Provider, Gruppen und Richtlinien leichter zugänglich als Keycloaks breiteres Realm- und Autorisierungsmodell.

Authelia kann einfacher sein, wenn Sie nur Authentifizierung am Reverse Proxy brauchen. ZITADEL ergibt mehr Sinn, wenn die Person, die Identität konfiguriert, ein Entwickler ist, der hauptsächlich über APIs arbeitet.