Authentik: Die Referenz-Architektur für souveränes Identity & Access Management (IAM)
Fabian Peter 5 Minuten Lesezeit

Authentik: Die Referenz-Architektur für souveränes Identity & Access Management (IAM)

Authentik definiert Identity Management neu: Weg von proprietären Cloud-Silos, hin zu einer unified Identity Layer. Als Open-Source-Lösung vereint es Authentifizierung, Enrollment und Autorisierung in einer hochflexiblen Engine. Im Gegensatz zu Cloud-Providern, die Nutzerdaten in geschlossenen „User Pools" einsperren, garantiert Authentik volle Datenhoheit und Portabilität der digitalen Identitäten über alle Infrastruktur-Grenzen hinweg.
identity-management access-management open-source unified-identity-layer policy-based-flows authentication data-portability

TL;DR

Authentik definiert Identity Management neu: Weg von proprietären Cloud-Silos, hin zu einer unified Identity Layer. Als Open-Source-Lösung vereint es Authentifizierung, Enrollment und Autorisierung in einer hochflexiblen Engine. Im Gegensatz zu Cloud-Providern, die Nutzerdaten in geschlossenen „User Pools" einsperren, garantiert Authentik volle Datenhoheit und Portabilität der digitalen Identitäten über alle Infrastruktur-Grenzen hinweg.

1. Das Architektur-Prinzip: Unified Identity Layer

In klassischen Cloud-Setups ist das Identitätsmanagement oft fragmentiert. Applikationen nutzen unterschiedliche Logins oder sind hart an den Identity Provider (IdP) des Cloud-Anbieters gekoppelt. Dies führt zu „Identity Sprawl" und Sicherheitslücken.

Authentik fungiert als zentraler Unified Identity Provider. Es abstrahiert die Authentifizierung von der Applikation.

  • Provider-Agnostik: Authentik spricht alle relevanten Protokolle (OIDC, SAML, LDAP, Proxy-Auth). Egal ob moderne Single-Page-App, Legacy-Software oder SSH-Zugang – Authentik zentralisiert den Zugriff.
  • Pipeline-Architektur: Anstatt statischer Login-Masken nutzt Authentik ein „Flow"-Konzept. Jeder Schritt (Login, MFA, Consent, Passwort-Reset) ist eine definierte Stage in einer Pipeline, die sich granular anpassen lässt.

2. Kern-Feature: Policy-based Flows und Flexibilität

Während proprietäre Lösungen oft nur starre „An/Aus"-Schalter für Konfigurationen bieten, setzt Authentik auf volle Programmierbarkeit.

  • Flows als Code: Authentifizierungsabläufe können per Drag-and-Drop oder Code definiert werden. Möchten Sie, dass Nutzer aus dem internen Netzwerk kein MFA benötigen, externe Nutzer aber schon? Das lässt sich über Policies abbilden.
  • Python-basierte Policies: Für komplexe Anforderungen können Administratoren kleine Python-Snippets hinterlegen, die dynamisch zur Laufzeit ausgewertet werden.

Dies ermöglicht Szenarien, die mit Standard-Cloud-Diensten unmöglich sind, ohne die Hoheit über den Authentifizierungsprozess an externe „Black-Box"-Logik abzugeben.

3. Brückenschlag: Legacy und Cloud-Native

Ein strategischer Vorteil von Authentik ist der integrierte Outpost-Mechanismus. Authentik kann nicht nur moderne Apps via OIDC schützen, sondern auch Legacy-Applikationen, die gar keine Authentifizierung besitzen.

Über einen „Proxy Provider" schaltet sich Authentik vor die Applikation. Der Nutzer authentifiziert sich am IdP, und Authentik reicht die Identität via Header an die Legacy-App weiter. Dies erlaubt „Zero Trust" Architekturen auch für Software, die vor 10 Jahren geschrieben wurde, ohne den Code anfassen zu müssen.

4. Betriebsmodelle im Vergleich: AWS Cognito vs. ayedo Managed Authentik

Hier entscheidet sich, wem die digitalen Identitäten – das wertvollste Gut eines Unternehmens – wirklich gehören.

Szenario A: AWS Cognito (Die Daten-Geiselhaft)

Wer Cognito nutzt, wählt den bequemsten Weg in den Vendor Lock-in. Die Nutzerdaten werden in einem AWS-proprietären „User Pool" gespeichert.

  • Der Password-Hash-Trap: Cognito erlaubt keinen Export der Passwort-Hashes. Möchten Sie den Provider wechseln, können Sie die Nutzerdaten nicht einfach migrieren. Alle Nutzer müssen ihre Passwörter zurücksetzen. Dies ist ein massives UX-Risiko und verhindert oft die Migration.
  • Proprietäre Trigger: Anpassungen am Login-Prozess erfordern AWS Lambda Funktionen mit spezifischen Payloads. Diese Business-Logik ist nicht portabel.
  • Das Resultat: Ihre Nutzerbasis gehört faktisch Amazon. Eine strategische Unabhängigkeit ist nicht gegeben.

Szenario B: Authentik mit Managed Kubernetes von ayedo

Im ayedo App-Katalog wird Authentik als souveräne Instanz bereitgestellt.

  • Volle Datenhoheit: Die Nutzerdaten liegen in einer Standard PostgreSQL-Datenbank in Ihrem Cluster (oder einem Managed Database Service Ihrer Wahl). Ein Export ist jederzeit per pg_dump möglich – inklusive der Passwort-Hashes.
  • Portable Logik: Die Konfiguration der Flows und Policies ist Teil des Deployments (Blueprints).
  • Echte Souveränität: Sie besitzen die Identitäten. Ob der Cluster bei AWS, Hetzner oder On-Prem läuft, spielt für das IAM keine Rolle.

Technischer Vergleich der Betriebsmodelle

Aspekt AWS Cognito (Proprietär) ayedo (Managed Authentik)
Datenhaltung AWS User Pool (Blackbox) Standard SQL (PostgreSQL)
Exportierbarkeit Eingeschränkt (Keine Passwörter!) Vollständig (Inkl. Hashes)
Anpassbarkeit AWS Lambda Trigger (Proprietär) Python Policies (Standard)
Protokolle OIDC, SAML (limitiert) OIDC, SAML, LDAP, Proxy
Strategisches Risiko Extremer Lock-in (Datenverlust bei Wechsel) Volle Souveränität
Lizenzkosten Pay-per-MAU (skaliert teuer) Open Source (skaliert kostenlos)

FAQ: Authentik & IAM Strategy

Authentik vs. Keycloak: Was soll ich nutzen?

Beide sind exzellente Open-Source-Tools. Keycloak ist der etablierte „Enterprise-Tanker" – extrem mächtig, aber komplex in der Verwaltung und ressourcenhungrig (Java-basiert). Authentik (Python/Go) ist moderner, leichtgewichtiger und bietet oft eine intuitivere Developer Experience („Flows"). Für moderne Kubernetes-Setups und Teams, die Flexibilität suchen, ist Authentik oft die agilere Wahl.

Kann ich Authentik für interne und externe Nutzer (Kunden) nutzen?

Ja. Authentik unterstützt Multi-Tenancy Konzepte. Sie können unterschiedliche „Brands" und Flows definieren. Interne Mitarbeiter melden sich z.B. via LDAP/Active Directory Sync an, während externe Kunden sich per Social Login (Google, GitHub) oder E-Mail registrieren. Alles wird in einer zentralen Instanz verwaltet.

Wie migriere ich von Auth0 oder Cognito zu Authentik?

Authentik bietet Import-Features. Da Cognito jedoch keine Passwörter herausgibt, ist die Strategie meist eine „Lazy Migration": Authentik wird als neuer IdP gesetzt. Beim ersten Login eines Nutzers prüft Authentik die Credentials transparent gegen den alten Provider (Cognito), migriert den Nutzer bei Erfolg in die eigene Datenbank und speichert das Passwort neu. So merken Nutzer nichts von der Migration.

Unterstützt Authentik Machine-to-Machine (M2M) Kommunikation?

Ja. Neben menschlichen Benutzern unterstützt Authentik Service-Accounts und API-Tokens. Sie können Zertifikate und Tokens für CI/CD-Pipelines oder Microservice-Kommunikation ausstellen und validieren, was es zu einer zentralen Sicherheitsinstanz macht.

Fazit

Identity ist der neue Perimeter. Wer seine Nutzerverwaltung an einen Hyperscaler wie AWS Cognito bindet, begibt sich in eine gefährliche Abhängigkeit, bei der ein Providerwechsel fast unmöglich wird. Authentik bietet die technologische Freiheit, diesen kritischen Layer selbst zu kontrollieren. Mit dem ayedo Managed Stack erhalten Unternehmen die Power einer Enterprise-IAM-Lösung, ohne sich um das Hosting von Datenbanken und Redis-Caches kümmern zu müssen. Das Ergebnis ist maximale Sicherheit bei voller strategischer Unabhängigkeit.

Ähnliche Artikel

Weekly Backlog KW 2/2026

Editorial: Patchen ist kein Nice-to-have KW 2 fühlt sich an wie ein Déjà-vu in Dauerschleife. …

06.01.2026