Es gibt Systeme, die kann man „mal eben“ outsourcen. Und es gibt Systeme, die sind so etwas wie die Wirbelsäule eurer kompletten digitalen Infrastruktur. Identitäten und Berechtigungen gehören für mich ganz klar zur zweiten Kategorie.
Wenn dein Identity Provider (IdP) wackelt, wackelt alles: VPN, E-Mail, Git, Kubernetes, Atlassian, HR-Tools, Passwortmanager, Cloud-Konsole – und im Zweifel auch dein Notfallzugang. Identität ist nicht nur „Login“. Identität ist Governance, Zugriff, Audit, Incident Response. Und damit: Souveränität.
Authentik (ja, klein geschrieben im Projekt) positioniert sich genau in diesem Spannungsfeld als Open-Source-IdP für modernes SSO – selbst betreibbar, von Homelab bis Cluster, mit SAML, OAuth2/OIDC, LDAP, RADIUS und mehr.
Warum man seine Authentifizierung als Rückgrat der kompletten digitalen Infrastruktur selbst betreiben sollte
1) Datenhoheit ist kein Buzzword – sie ist ein Betriebsmodell
Wir haben das bei Honicon schon bei anderen „Basisdiensten“ sehr bewusst so entschieden: Daten sollen nicht „irgendwo“ über Server Dritter laufen, nur weil es gerade bequem ist. Der Punkt ist nicht Paranoia – der Punkt ist Kontrolle: Welche Logs entstehen? Wo liegen sie? Wer kann sie sehen? Wie schnell komme ich im Ernstfall ran?
Bei einem IdP ist das noch schärfer:
- Login-Metadaten sind Gold (wer, wann, wo, womit, von welchem Gerät/IP, welche App).
- Policies sind Macht (wer darf was, unter welchen Bedingungen).
- Audit-Trails sind Haftung (Nachweisbarkeit, Revisionssicherheit, Incident Timeline).
Wenn Identität „Cloud-only“ ist, ist dein Kontrollradius automatisch kleiner – selbst wenn der Anbieter technisch top ist.
2) Vendor Lock-in passiert nicht schlagartig – er passiert still
Lock-in ist selten ein „Wir können nicht weg“. Lock-in ist eher:
- Preismodell ändert sich, und plötzlich wird jede Sicherheitsfunktion „P2“, „Advanced“, „Premium“.
- Du passt deine Prozesse an den Anbieter an („so macht man das halt hier“).
- Deine Apps hängen an proprietären Features statt an Standards.
Authentik setzt bewusst auf Standardprotokolle (SAML, OIDC/OAuth2, LDAP etc.). Das klingt langweilig – ist aber der Trick, wie du in fünf Jahren noch handlungsfähig bist.
3) Resilienz: Wenn dein IdP down ist, ist dein Unternehmen… offline
Ein selbst betriebener IdP bedeutet nicht automatisch „mehr Ausfall“. Im Gegenteil: Du kannst ihn so bauen, wie du deine Verfügbarkeit wirklich brauchst – vom einfachen Docker-Setup bis zum Kubernetes/Helm-Betrieb.
Und für Umgebungen, die nicht „einfach ins Internet dürfen“ (firewalled, getrennte Netze, Standorte), bringt Authentik das Konzept der Outposts mit, die genau solche Szenarien unterstützen.
4) Sicherheit: Zero Trust fängt bei Identity an, nicht beim Firewall-Regelwerk
Microsoft beschreibt Conditional Access als „Zero Trust Policy Engine“, die Signale einsammelt und Policies durchsetzt. Der Punkt ist richtig – nur muss diese Engine nicht zwingend in der Cloud wohnen.
Authentik denkt mit Flows, Stages und Policies in modularen Bausteinen: Authentifizierung, Enrollment, Recovery, Freigaben – als zusammensetzbare Workflows.
Kritischer Realitätscheck: Selbst betreiben heißt auch selbst patchen, monitoren, backuppen, härten, testen. Wer das nicht ernst nimmt, ist mit „Cloud“ manchmal objektiv besser bedient. Souveränität ist kein Gratis-Buffet – sie ist Verantwortung.
Wie sich Authentik gegen andere Open-Source-Authentifizierungslösungen (z.B. Keycloak) behauptet
Keycloak ist der Platzhirsch im Open-Source-IAM. Verdient. Riesige Community, lange Historie, enterprise-erprobt. Keycloak setzt ebenfalls stark auf Standards wie OpenID Connect und SAML 2.0.
Warum also Authentik?
1) Pragmatismus & „Glue“-Mentalität statt reines IdP-Dogma
Authentik nennt sich selbst „authentication glue“ – und das trifft es: Es will nicht nur „Token ausgeben“, sondern Apps in heterogenen Landschaften zusammenkleben.
Dazu gehören Dinge wie:
- Proxy/Application Gateway-Ansatz für Apps ohne SSO-Fähigkeit (Provider/Proxy, Outposts).
- SCIM als Provider zum Provisioning in Zielsysteme.
Keycloak kann extrem viel – aber häufig endet man schneller im „IAM-Projekt“ statt in einer Lösung, die man neben dem Tagesgeschäft sauber betreiben kann.
2) Flows/Staging: visuelle Workflows statt „Konfigurationsarchäologie“
Authentik macht seine Baustein-Philosophie ziemlich explizit: Flows + Stages + Policies sind „at the heart“ des Systems.
Das ist nicht nur UX – das ist ein anderer Denkansatz: Du modellierst Anmelde- und Sicherheitslogik als Ablauf.
Keycloak ist ebenfalls flexibel, aber viele Teams erleben die Flexibilität eher als: „Es gibt drei Wege, und alle haben irgendwo Haken.“
3) Breite Protokoll-Abdeckung inkl. Legacy-Anker
Authentik listet neben OIDC/SAML auch LDAP und weitere Integrationen als Standard-Provider auf.
Gerade in deutschen Mittelstandslandschaften ist „Legacy“ kein Schimpfwort, sondern Realität: NAS, Druck-Services, ältere VPNs, Gerätezugänge. Da hilft es, wenn das IAM nicht nur Web-SSO kann, sondern auch Brücken baut.
4) MFA & moderne Authenticatoren: TOTP und WebAuthn/Passkeys
Authentik bringt Stages für TOTP und WebAuthn/Passkeys mit.
Das ist relevant, weil „MFA an“ nicht gleich „phishing-resistent“ ist. WebAuthn/Passkeys sind ein echter Sicherheitshebel, wenn man sie sinnvoll ausrollt.
Kritischer Realitätscheck: Keycloak hat in großen Enterprises eine enorme Verbreitung, Integrationsbreite und Know-how im Markt. Wenn du ein Team hast, das Keycloak wirklich kann – oder sowieso ein Java/Quarkus-nahes Ökosystem – kann Keycloak die bessere Wahl sein. Authentik gewinnt oft dort, wo Teams Geschwindigkeit + klare Modellierung + „Glue“ brauchen.
Wie sich Authentik gegen proprietäre Lösungen wie Entra ID oder Okta schlägt
Hier muss man fair sein: Entra ID und Okta sind nicht erfolgreich, weil alle Menschen im Einkauf schlafen. Die Produkte sind stark – vor allem, wenn du genau deren Ökosystem spielst.
Microsoft Entra ID: brutal gut in Microsoft-Welten – und sehr mächtig über Conditional Access
Entra ID unterstützt SSO über OIDC und SAML (Microsoft dokumentiert beides sehr ausführlich) und bietet Conditional Access als zentrale Policy-Engine.
Wenn du stark in M365/Azure steckst, ist Entra oft „die natürliche Schwerkraft“.
Wo Authentik dagegen punktet:
- Du willst Identität nicht als Teil eines einzelnen Hyperscaler-Stacks, sondern als eigenständige Sicherheitsdomäne.
- Du willst Standardprotokolle so nutzen, dass ein späterer Wechsel nicht zur Operation am offenen Herzen wird.
- Du willst Workflows/Enrollment/Policies selbst gestalten, ohne dass jedes Feature an ein Lizenzlevel gekoppelt ist (realistisch betrachtet: ein häufiger Pain).
Okta: sehr reif, sehr breit, aber (wie jeder große Anbieter) ein attraktives Ziel
Okta ist ein mächtiger IdP; auch dort sind OIDC und SAML zentrale Integrationspfade.
Aber: Identity-Anbieter sind Hochwertziele. Und Okta hatte u. a. den öffentlich diskutierten Support-System-Sicherheitsvorfall (Oktober 2023) – Okta selbst hat Updates und empfohlene Maßnahmen veröffentlicht, und die Berichterstattung zeigte, dass die Reichweite größer war als initial kommuniziert.
Das ist kein „Okta-bashing“. Das ist die nüchterne Erkenntnis: Wenn du einen zentralen IdP einkaufst, kaufst du auch dessen Risikoprofil – inklusive Transparenz, Incident-Kommunikation, Drittparteien, Support-Prozesse.
Wo Authentik dagegen punktet:
- Du kannst Betrieb, Logging, Zugriff auf Supportdaten, Admin-Prozesse und Schlüsselmaterial selbst definieren.
- Du reduzierst die Anzahl externer Stellen, bei denen Identitätsdaten und Token-Flows „durchlaufen“.
Kritischer Realitätscheck:
Cloud-IdPs gewinnen oft bei:
- extrem schneller Skalierung,
- sehr tiefen SaaS-Integrationen,
- „Device + Identity“-Kombination (Compliance, Managed Devices),
- Einkauf/Standardisierung („ein Vertrag, ein Portal“).
Authentik gewinnt oft bei:
- Souveränität,
- Kosten- und Modellkontrolle,
- Integrationsfreiheit in gemischten Landschaften,
- On-Prem / Hybrid / segmentierten Netzen (Outposts).
| Kriterium | Authentik | Keycloak | Entra ID / Okta |
|---|---|---|---|
| Souveränität | ✅ Vollständig selbst kontrolliert | ⚠️ Abhängig von Community/Red Hat | ❌ Cloud-Abhängigkeit |
| Legacy-Integration | ✅ LDAP, RADIUS, Outposts, SCIM, Kerberos | ⚠️ LDAP, SAML, OIDC (eingeschränkt) | ❌ Fokus auf moderne Protokolle |
| Betriebsaufwand | ⚠️ Eigenverantwortung (Kubernetes, Docker, Terraform) | ⚠️ Komplex (Java/Quarkus, Cluster) | ✅ Gemanaged Service |
| Admin-Ausbildung | ⚠️ Kenntnisse in IAM, Kubernetes, IaC (Infrastructure as Code) | ⚠️ Java/Quarkus, IAM, Cluster-Management | ✅ Cloud-Zertifizierungen (z. B. Azure/Okta) |
| Kern-Themen | ✅ Open Source, Workflow-Automatisierung, Self-Hosting, FIPS-Compliance, WebAuthn/Passkeys, GeoIP, Application Proxy | ✅ Open Source, OIDC/SAML, Community-Support | ✅ Enterprise-Support, tiefe SaaS-Integration, Conditional Access |
| MFA & Moderne Auth | ✅ WebAuthn/Passkeys, TOTP, GeoIP | ✅ TOTP, WebAuthn (Plugin-basiert) | ✅ WebAuthn, Adaptive MFA |
| Remote Access | ✅ RDP, VNC, SSH | ❌ Nicht nativ | ⚠️ Über Drittanbieter |
| Protokollunterstützung | ✅ OIDC, SAML, LDAP, RADIUS, SCIM, Kerberos | ✅ OIDC, SAML, LDAP, SCIM | ✅ OIDC, SAML, SCIM (kein RADIUS) |
| Preismodell | ✅ Transparent, keine versteckten Kosten | ✅ Open Source (kostenpflichtiger Support) | ❌ Komplex, Feature-basierte Kosten |
| Skalierbarkeit | ✅ Kubernetes, Terraform, Docker Compose | ⚠️ Cluster-basiert | ✅ Automatische Skalierung |
| Use Cases | ✅ Authentifizierung, Enrollment, Self-Service, B2B/B2C | ✅ Authentifizierung, B2B | ✅ B2B/B2C, Enterprise-IAM |
Die saubere Entscheidung ist selten „Cloud gut / Selfhost gut“, sondern: Welche Abhängigkeiten sind für euch akzeptabel – und welche nicht?
Identitäten und Berechtigungen clever selbst verwalten – ohne Hype, ohne Abhängigkeit
Wir bei Honicon haben irgendwann verstanden: Identitäten und Berechtigungen sind nicht nur ein technisches Thema – sie sind ein Prozess-Thema. Und genau da scheitern viele Umsetzungen: SSO läuft, MFA läuft, alles schick – aber die Frage „Wer hat wem wann warum Zugriff gegeben?“ endet im besten Fall in einem Wiki-Fragment und im schlimmsten Fall in Schulterzucken.
Deshalb nutzen wir authentik nicht isoliert, sondern als Bestandteil unserer Abläufe – gekoppelt an unser tägliches Arbeitswerkzeug: Atlassian Jira und Plane.so. Die Idee ist simpel:
- Identitäten, Rollen und Zugriffsanfragen werden nicht „irgendwo“ entschieden, sondern als nachvollziehbarer Vorgang behandelt.
- Freigaben passieren dort, wo ohnehin gearbeitet wird (Tickets/Requests, Zuständigkeiten, Vier-Augen-Prinzip, Fristen).
- Und das Beste: Die Dokumentation und Nachweisführung fürs ISMS fällt dabei quasi als Nebenprodukt ab – weil Entscheidungen, Begründungen, Änderungen und Reviews bereits im Prozess entstehen, statt später mühsam nachgetragen zu werden.
Wenn ihr Souveränität ernst meint, fangt nicht bei der hundertsten App-Integration an, sondern bei der Frage: Wie treffen wir Zugriffsentscheidungen – und wie beweisen wir sie?
Wenn ihr wollt, schauen wir gemeinsam auf eure Landschaft (Apps, Standards, Legacy, Verantwortlichkeiten) und bauen eine Lösung, die nicht nur „Login kann“, sondern Betrieb, Audit und ISMS gleich mitdenkt – ohne künstlichen Mehraufwand, aber mit echter Kontrolle.
