Authentik vs. Auth0 & Okta: Open-Source Identity Provider und Single Sign-On

In einer modernen Zero-Trust-Sicherheitsarchitektur ist die digitale Identität der neue Netzwerkperimeter. Jede interne Fachanwendung, jedes Kundenportal, jeder Kubernetes-Cluster und jede externe API verlässt sich bei der Zugriffskontrolle auf einen zentralen Identity Provider (IdP) und ein durchgängiges Single Sign-On (SSO). Fällt dieser zentrale Authentifizierungsdienst aus oder wird er kompromittiert, steht das gesamte Unternehmen augenblicklich still.

Über Jahre hinweg haben viele Software-Teams und IT-Abteilungen diese kritische Schlüsselfunktion an US-amerikanische Cloud-Dienste wie Auth0 oder Okta ausgelagert. Der Einstieg über kostenlose Entwickler-Tarife ist verlockend einfach, doch sobald das Unternehmen wächst, B2B-Kunden per SAML anbinden möchte oder mehr als wenige tausend monatlich aktive Nutzer (MAU) verzeichnet, vervielfachen sich die Lizenzkosten schlagartig auf sechsstellige Jahresbeträge.

Mit Authentik hat sich neben dem traditionsreichen Java-Schwergewicht Keycloak ein moderner, Cloud-nativer Open-Source Identity Provider etabliert, der höchste Sicherheit, einfache Bedienbarkeit und volle Datensouveränität im eigenen Rechenzentrum vereint.

Die Architektur von Authentik: Warum SSO, RBAC und Legacy-Apps zusammenwachsen

In historisch gewachsenen IT-Landschaften scheitert ein flächendeckendes Single Sign-On meist daran, dass nicht jede Anwendung moderne Web-Standards spricht. Während neue Cloud-Apps OpenID Connect (OIDC) erwarten, verlangen ältere Enterprise-Systeme SAML 2.0, Netzwerkswitches und VPN-Gateways benötigen RADIUS oder LDAP, und selbst entwickelte interne Administrations-Tools besitzen überhaupt keine SSO-Schnittstelle.

Authentik löst diese Protokoll-Fragmentierung durch eine modulare Outpost- und Flow-Architektur auf Basis von Python und Go:

• Universeller Protokoll-Übersetzer: Ein einziger zentraler Benutzerstamm bedient gleichzeitig OIDC/OAuth2, SAML 2.0, SCIM-Provisionierung sowie dedizierte LDAP- und RADIUS-Outposts für die Netzwerkinfrastruktur.
• Integrierter Forward-Auth-Proxy: Über direkte Integration mit Ingress-Controllern wie Traefik, NGINX oder Envoy schaltet Authentik eine sichere Anmeldeschranke vor ältere Webanwendungen, ohne dass an deren Quellcode eine einzige Zeile geändert werden muss.
• Dynamische Rollen (RBAC und ABAC): Zugriffsrechte werden nicht nur starr über Gruppen (Role-Based Access Control), sondern dynamisch über Python-basierte Richtlinien (Attribute-Based Access Control, z. B. Tageszeit, IP-Subnetz oder Gerätestatus) ausgewertet.
• Souveräne Bot-Abwehr ohne CAPTCHAs: Anstatt Anmeldeseiten mit US-amerikanischen Drittanbieter-CAPTCHAs zu versehen, die Nutzerdaten abgreifen, schützt Authentik Login-Flows durch Rate-Limiting, Reputation-Scoring, WebAuthn-Passkeys und datenschutzkonforme Turnstile-/Proof-of-Work-Stufen.

Wie Sie die Authentifizierung selbst gegen Man-in-the-Middle-Angriffe immunisieren, lesen Sie in unserem Leitfaden zu Phishing-resistenter MFA mit FIDO2 und Passkeys.

Ergänzende Architektur-Analysen und technische Entscheidungsmatrizen für Ihre IT-Planung finden Sie in unseren weiterführenden Leitartikeln zu OPNsense vs Fortinet im Enterprise-Einsatz sowie zu Keycloak IAM im Enterprise-Einsatz.

Authentik versus Keycloak versus Auth0/Okta: Wann passt welche Plattform?

Wenn sich CIOs und Enterprise-Architekten gegen den Lock-in von Auth0 oder Okta entscheiden, stehen im Open-Source-Lager vor allem zwei leistungsstarke Kandidaten zur Auswahl: der langjährige Platzhirsch Keycloak (Red Hat / CNCF) und das modernere Authentik.

Ein objektiver Architekturvergleich zeigt klare Stärken für unterschiedliche Einsatzszenarien:

• Authentik für Cloud-Native-Teams und Infrastruktur-Konsolidierung: Authentik glänzt durch eine hochmoderne Benutzeroberfläche, den grafischen Flow-Designer, den eingebauten Forward-Auth-Proxy sowie die nativen LDAP- und RADIUS-Outposts. Zudem lässt sich die gesamte Konfiguration vollständig über einen offiziellen Terraform-Provider als Code verwalten.
• Keycloak für tiefgehende Java-Ökosysteme und Telco-Skalierung: Wer bereits hunderte Java-/Quarkus-Entwickler beschäftigt und hochspezialisierte Finanz- oder Telekommunikationsprofile (wie FAPI 2.0) für dutzende Millionen Endkunden benötigt, findet in Keycloak ein extrem reifes, wenn auch komplexer zu konfigurierendes System.
• Unabhängigkeit von externen Cloud-Störungen und Sicherheitsvorfällen: Ein im eigenen Rechenzentrum oder privaten Kubernetes-Cluster betriebener Identity Provider stellt sicher, dass Ihre Mitarbeiter und Produktionssysteme selbst bei einem globalen Ausfall amerikanischer Cloud-Dienste uneingeschränkt arbeitsfähig bleiben.
• Automatisches Onboarding und Offboarding per SCIM 2.0: Tritt ein Mitarbeiter in das Unternehmen ein oder verlässt es, synchronisiert Authentik die Benutzerrollen und Sperrungen automatisch mit dem HR-System und allen angeschlossenen Fachapplikationen.

„Wer den Haustürschlüssel zu sämtlichen Unternehmensanwendungen und Kundendatenbanken an einen externen Cloud-Drittanbieter vermietet, gibt den innersten Kern seiner Sicherheitsarchitektur aus der Hand.“

Wie sich ein zentraler Identity Provider in eine ganzheitliche Sicherheitsarchitektur einfügt, erläutert unser Dossier zu Enterprise Cyber-Resilience und Zero-Trust-Architektur.

System-Matrix: Auth0 / Okta (SaaS) versus Authentik (Open-Source Self-Hosted)

Die folgende Übersicht stellt die architektonischen und kaufmännischen Eigenschaften von kommerziellem IDaaS und selbst betriebenem Authentik gegenüber:

Wirtschaftliche TCO-Analyse^*: B2B-/B2C-Plattform mit 25.000 externen Nutzern und 500 Mitarbeitern

Für ein Unternehmen, das sowohl seine 500 internen Mitarbeiter (Workforce Identity) als auch 25.000 externe Kunden und Partner (Customer Identity / CIAM mit 25 B2B-SAML-Mandanten) über Single Sign-On absichert, ergibt sich über 36 Monate folgende Gesamtkostenrechnung:

Der größte strategische Vorteil zeigt sich bei der Skalierung: Wächst das Kundenportal im vierten Jahr von 25.000 auf 100.000 aktive Nutzer, bleiben die Infrastrukturkosten bei Authentik nahezu unverändert, während bei kommerziellen Cloud-Anbietern sofort ein massiver Vertragssprung fällig wird.

Der 4-Phasen-Migrationspfad von Auth0/Okta oder Legacy-AD zu Authentik

Ein Wechsel des zentralen Identity Providers muss für Endanwender völlig unterbrechungsfrei ablaufen (Zero-Downtime-Migration). In der Praxis hat sich folgendes vierstufiges Vorgehen bewährt:

Phase 1 (Monat 1): Hochverfügbares Cluster-Setup und Infrastructure-as-Code

Bereitstellung von Authentik im Kubernetes-Cluster (Helm-Chart) mit einem hochverfügbaren PostgreSQL-Datenbank-Cluster. Anlegen aller Authentifizierungs-Flows und Rollenmodelle über den offiziellen Terraform-Provider in einem Git-Repository.

Phase 2 (Monat 2): Identity Brokering und transparente Passwort-Migration

Kopplung von Authentik mit dem bestehenden Active Directory oder Altsystem. Falls Passwort-Hashes aus der alten Cloud nicht exportierbar sind, validiert ein kurzer Migrations-Hook das Passwort beim ersten Login einmalig gegen die alte API und speichert den neuen Argon2-Hash lokal ab.

Phase 3 (Monat 3): Schrittweise Umstellung der OIDC-, SAML- und Proxy-Applikationen

Umschaltung der internen und externen Fachanwendungen auf die neuen OIDC- und SAML-Endpunkte von Authentik. Absicherung älterer interner Web-Oberflächen über den integrierten Forward-Auth-Outpost am Ingress-Gateway.

Phase 4 (Monat 4): Rollout von FIDO2-Passkeys und Abschaltung des Altvertrags

Aktivierung verpflichtender Multi-Faktor-Authentifizierung (WebAuthn/Passkeys oder TOTP) für alle Benutzerrollen, Anbindung des Audit-Streams an das zentrale SIEM-System und fristgerechte Kündigung der teuren IDaaS-Altverträge.

Fünf Kontrollfragen für CIOs, CISOs und Plattform-Architekten

1. Bestraft Ihr aktueller IAM-Lizenzvertrag das Wachstum Ihrer digitalen Kundenportale?

Steigen Ihre Lizenzkosten linear oder sprunghaft an, sobald sich mehr Kunden in Ihrem Portal registrieren oder ein neuer B2B-Großkunde eine eigene SAML-Kopplung (Enterprise Federation) verlangt?

2. Wie viele interne Web-Tools laufen noch ohne zentrales Single Sign-On?

Existieren in Ihrem Unternehmensnetzwerk noch ältere Administrations-Oberflächen oder Eigenentwicklungen mit getrennten lokalen Passwörtern, weil ihnen eine moderne OIDC-Schnittstelle fehlt?

3. Werden ausgeschiedene Mitarbeiter in derselben Minute in allen Systemen gesperrt?

Sorgt ein zentraler Identity Provider mit SCIM-Provisionierung dafür, dass bei einer Vertragsbeendigung im HR-System sofort sämtliche aktiven Sitzungen und API-Tokens widerrufen werden?

4. Ist Ihre gesamte IAM-Konfiguration als Code (GitOps) wiederherstellbar?

Können Sie Ihre gesamten Anmelde-Flows, Benutzerrollen und App-Verbindungen nach einem Ausfall per Knopfdruck über Terraform reproduzierbar neu ausrollen, statt hunderte Klicks in einer Web-Oberfläche zu wiederholen?

5. Nutzen Sie auf Ihren Login-Seiten noch externe Drittanbieter-CAPTCHAs?

Übertragen Ihre Anmeldeformulare beim Laden unbemerkt IP-Adressen und Browser-Fingerprints Ihrer Mitarbeiter und Kunden an außereuropäische Werbe-Konzerne?

Strategisches Fazit: Digitale Identitäten gehören unter eigene Hoheit

Identity und Access Management ist das Fundament jeder modernen IT-Sicherheitsstrategie. Kommerzielle Cloud-Anbieter haben dieses Fundament in ein hochprofitables Mautsystem verwandelt, bei dem Unternehmen für jeden aktiven Nutzer und jede Sicherheitsfunktion dauerhaft zur Kasse gebeten werden.

Mit Authentik (oder Keycloak bei tiefen Java-Landschaften) übernehmen CIOs und DevOps-Teams wieder selbst die Kontrolle über ihre digitale Eingangstür. Sie vereinen Single Sign-On, feingranulare Benutzerrollen und Phishing-resistente Passkeys auf einer offenen Plattform, die ohne künstliche Lizenzgrenzen mit dem Unternehmen wächst.

Häufig gestellte Fragen (FAQ) zu Authentik, Single Sign-On und Open-Source-IAM