Identität & SSO

authentik: einmal anmelden, alles nutzen.

Nutzer melden sich ein einziges Mal an und erreichen danach jeden Service – auf einer Landingpage sehen sie, was für sie freigegeben ist. Dahinter: ein Identity Provider, der jeden Zugriff über Caddy-Forward-Auth absichert. Warum das für Nutzer und Betrieb gewinnt, was authentik ausmacht und wie eine Anmeldung abläuft.

Warum authentik

Single Sign-On · ein Dashboard

Ohne SSO hat jede App ihren eigenen Login – eigene Passwörter, eigene Sessions, eigene Reibung. Mit authentik gibt es eine Anmeldung: Danach öffnet jeder Service ohne erneutes Einloggen, und auf dem Application Dashboard sehen Nutzer genau die Services, die für sie freigegeben sind. Für Nutzer ist das Bequemlichkeit – für den Betrieb bedeutet es zentrale Kontrolle: Provisionierung, MFA und Offboarding an einer Stelle.

Für Metabase einloggen, für pgweb nochmal, für Dagster nochmal. Jede App eine eigene Benutzerliste – und man muss die URLs kennen.

SSO mit authentik

Einmal anmelden, dann alles nutzen. Ein Dashboard zeigt alle Services; ein Klick genügt, die Session gilt für alle.

Nutzersicht

Einmal anmelden, alles nutzen

Eine Identität, eine Session. Nach dem ersten Login öffnet jeder weitere Service sofort – kein erneutes Passwort, kein erneutes MFA.

Landingpage

Alle Services an einem Ort

Das Application Dashboard zeigt jedem Nutzer seine freigegebenen Apps. Self-Service statt URL-Zettel und Weitergabe von Zugängen.

Application Proxy

SSO auch für Apps ohne SSO

Der Proxy-Outpost hängt selbst Tools ohne eigenes Login an – z. B. pgweb – und injiziert Identity-Header wie X-authentik-username.

Betrieb

Ein Gate, self-hosted

Zentrale Kontrolle über Zugriff, MFA und Offboarding – in eigener Hand, EU-souverän, als Overlay zum portablen Stack.

In unserem Stack ist authentik das einzige Gate – Forward-Auth via Caddy. Im Lock-Session-Modus (pgweb) ist der Zugriff auf eine dedizierte Admin-Gruppe beschränkt, denn der Blast Radius wäre voller DB-Zugriff. Aktuell: authentik 2026.5 · seit Release 2025.10 ohne Redis (PostgreSQL-only).

Was ist authentik

Building Blocks · Laufzeit

Ein Open-Source-IdP und SSO-Plattform in zwei Rollen: als Identity Provider (Apps authentifizieren gegen authentik) und als Consumer (Nutzer loggen sich via externe Sources ein – Federation). Kern sind die Building Blocks: Flows aus Stages, gated durch Policies. Geschrieben in Python (Django) mit Go-basierten Outposts fürs Protokoll-Proxying.

Building Blocks

Konfiguration

ApplicationEine geschützte App – erscheint als Kachel im Dashboard.FlowSequenz von Stages: Login, Enrollment, Recovery, Authorization.StageEinzelner Schritt: Identification, Password, MFA, User Login.PolicyRegel, an Flow/Stage gebunden – erlaubt, verweigert, verzweigt.ProviderWie Auth bereitgestellt wird: OIDC, SAML, LDAP, Proxy, RADIUS, SCIM.SourceExterne Identität (Federation): Google, GitHub, LDAP/AD, SAML.BrandBranding & Default-Flows pro Domain (früher Tenant).

Laufzeit & Deployment

Was läuft

ServerDjango-Core: Identitätslogik, API, Flow-Ausführung.WorkerHintergrundaufgaben (seit 2026.5 mit Rust-Entrypoint).PostgreSQLPersistenter Speicher – Users, Config, Sessions.OutpostGo-Protokoll-Brücke: Proxy (Forward-Auth), LDAP, RADIUS, RAC.Embedded OutpostProxy-Outpost, standardmäßig im Server eingebettet.

Merksatz: Der Nutzer sieht das Dashboard und seine Apps – dahinter regeln Flows, Policies und der Outpost, ob und wie jeder Zugriff gewährt wird.

Wie es abläuft

läuft · Endlosschleife

Zwei Schritte: Zuerst der erste Login – Caddy delegiert per forward_auth an den Outpost, keine Session, also läuft der Authentication-Flow. Danach landet der Nutzer auf dem Application Dashboard und öffnet jeden Service ohne erneutes Anmelden – die Session gilt für alle.

Schritt 01Der erste Login – wie es funktioniertforward_auth · Flow

NutzerBrowserGET /metabase

request

Reverse ProxyCaddyforward_auth

delegate

OutpostProxykeine Session

redirect

Authentication Flow · Policies prüfen

IdentificationPasswordMFAUser Login

issue

ErgebnisSessiongilt für alle Apps

Ablauf: keine Session → Flow durchlaufen (Identification → Password → MFA → User Login) → Session erstellt. Genau einmal.

Schritt 02Einmal anmelden, alles nutzenApplication Dashboard · SSO

ngo.datasolutions · Application DashboardTthanh · admin

MetabaseBI · Dashboardsgesperrt

pgwebDB-UI · via Proxygesperrt

DagsterOrchestrierunggesperrt

GrafanaMonitoringgesperrt

0× LoginNoch nicht angemeldet

Nach dem einen Login öffnet jeder Klick den Service sofort – der Outpost prüft nur die bestehende Session, kein weiterer Flow.

LaufzeitPostgreSQL-only · kein Redis seit 2025.10

server · coreworker · eventspostgresql · users & sessionsembedded outpost · proxy

“Einmal anmelden – der Rest ist nur eine gültige Session.”

— Single Sign-On · ein Gate