senn-techSSO for the Self-Hosted Stack: Authentik and Keycloak Compared
Anyone running a self-hosted stack seriously ends up with ten logins sooner or later. Each tool brings its own user database, each forgets a password, each has a different MFA implementation. The answer is an identity provider — and it should come before the tools, not after.
What SSO brings
- One login, all services: A single sign-in opens Nextcloud, Gitea, Zammad, the mail web client, and chat.
- One place for MFA: Two-factor is enforced centrally, not configured per tool. WebAuthn/passkeys included.
- One place for offboarding: A user who leaves is locked once — everywhere.
- LDAP/AD integration: Existing directories stay the source of truth; the IdP speaks to them.
The two serious open-source options
- Keycloak is the incumbent. Java, mature, backed by Red Hat, speaks every relevant protocol (OIDC, SAML, LDAP). Powerful, but heavyweight — and configurationally demanding.
- Authentik is the younger challenger. Python, leaner, with a modern UI and more flexible flows (visualised login chains). Less legacy, but a smaller community.
Both support OIDC, SAML, and LDAP integration. For a greenfield stack we lean toward Authentik; for integration into an existing enterprise IT with SAML requirements, often toward Keycloak.
How the integration works
- Each tool is registered as a Relying Party (client) in the IdP — with redirect URL and client secret.
- On login, the tool forwards to the IdP, the user authenticates there (including MFA), and a signed token comes back.
- The IdP can carry claims (groups, roles) so the tool knows the user's rights — without maintaining its own users.
What is often forgotten
- Security policy: The IdP becomes the single point of authentication. MFA is not optional — running it without a second factor concentrates the risk instead of dispersing it.
- Backup & HA: An IdP outage takes down the entire stack. Replicated database and regular backups are mandatory, not nice-to-have.
- Session management: Token validity and refresh behaviour must be set deliberately — overlong sessions are a weak point.
Our Take
SSO is not a comfort feature, it is security architecture. Whoever takes MFA seriously cannot enforce it per tool — only centrally. And whoever wants clean offboarding needs one place where a user exists. Authentik and Keycloak deliver that on-prem, without a third-party dependency.
Why Authentik instead of Keycloak — or vice versa?+
For a greenfield stack we lean toward Authentik: Python, lean, modern UI, more flexible flows. Keycloak is the incumbent — Java, mature, Red Hat-backed, speaks every relevant protocol. Integrating into existing enterprise IT with SAML requirements, you are often better served with Keycloak. Both support OIDC, SAML, and LDAP.
Isn’t running our own identity provider a lock-in risk?+
Quite the opposite: Authentik and Keycloak are open source and speak open standards (OIDC, SAML, LDAP). Switching is technically feasible because every tool talks the same protocols as a relying party. The real risk is running the IdP without replication and backups — then it becomes the single point of failure for your entire stack.
When does SSO pay off for a smaller company?+
From three to four self-hosted services with their own logins, a central IdP pays off — not just for convenience, but because MFA can only be enforced cleanly in one place and offboarding happens at a single point. Below that, the effort often outweighs the benefit. It is more a question of stack size than of company size.